The Google Chrome team has been working on a new feature and standard that aims to replace or augment traditional authentication cookies with cryptographic keys that are securely stored on and bound to the devices where they were generated. The solution aims to disrupt cybercriminal operations that rely on stealing session cookies through malware and using them to access accounts without authorization.
The new feature is called Device Bound Session Credentials (DBSC) and will be available for trial in Chrome Beta, first with Google accounts, but later for all websites that want to opt into using it. To securely store the private authentication keys locally on devices the new protocol will use the Trusted Platform Module (TPM) crypto processors that many new computers come equipped with, but the engineers are also considering supporting software-based secure storage options.
“By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value,” the Chrome engineers said in a blog post. “We think this will substantially reduce the success rate of cookie theft malware. Attackers would be forced to act locally on the device, which makes on-device detection and cleanup more effective, both for antivirus software as well as for enterprise-managed devices.”
Why is cookie theft an issue?
Session cookies are small text files that websites create inside browsers in order to identify a user’s active session after authentication. These cookies have long been a target for information-stealing trojans that scan infected systems for credentials, access tokens and other sensitive information stored inside various applications including all major browsers. This information is often sold on the underground market for use by other cybercriminals in subsequent attacks.
Session cookies are a valuable commodity because they are created after two-factor authentication to prevent the user from having to reauthenticate too often while interacting with a site. Websites can force a refresh of these cookies on users’ devices by invalidating the authenticated sessions they’re associated with and forcing the user to go through the authentication process again. As such, many of these cookies are long-lived and can be abused once stolen even if the malware is later detected and removed from the local system.
There is currently no safe way for browser vendors to protect cookies from being stolen by malware that runs with the same or higher privileges than the browser itself on a desktop operating system. The new DBSC mechanism is designed to solve that problem by augmenting existing cookies with cryptographic validation that cannot be compromised by malware.
How does DBSC prevent cookie theft?
The DBSC API will let a website tell the browser to start a new session and generate a private-public key pair for that session. The browser will then register the public key with the website using an endpoint path specified by the website and the website will then respond with short-lived cookies that are now associated with that public key.
The difference is the website can periodically request the browser for proof that it has the private key that’s part of the private-public key pair by asking it to sign a challenge. The challenge signature is then checked using the public key that was registered with the server when the session was created.
This private key needed to sign the challenge is stored securely and operations involving it are done via the computer’s TPM which has dedicated memory that is not accessible from within the operating system. This means the keys are kept secure from theft even in case of a full system compromise.
TPM chips have long been available in enterprise computers and laptops to support secure disk encryption and authentication, but they are now increasingly common in all types of PCs because the presence of a TPM 2.0 chip is a requirement for installing Windows 11. Studies done by the Chrome team suggest that currently over 60% of users have such a chip in their computers and the figure is only expected to increase.
TPM introduces a potential threat to DBSC
The problem with TPMs, however, is that they tend to have a high latency — the operations are not fast — and they have limited processing power which means they can’t handle many concurrent operations. Some users have already raised the issue of potential denial-of-service attacks performed by malicious domains and subdomains against TPMs via this feature by requesting key generation and validation for a large number of sessions at the same time.
The Chrome engineers responded that they already have a prioritization queue mechanism in mind and are exploring other protections to mitigate that threat.
One option is to use software-based secure key storage solutions like the one that Microsoft is currently testing in Windows 11 and which uses virtualization-based Security (VBS). This would address the latency issues and some of the risks.
It’s worth noting that DBSC will not solve attacks where the user’s active sessions are abused to perform unauthorized actions on their behalf by the malware commandeering their local browsers. However, such local browser hijacking is much noisier and easier to detect by security products than cookie theft.
With DBSC, cookies will still exist and can be stolen but they will be short-lived, which will severely limit the window of time in which attackers can abuse them. The protocol allows websites to refresh cookies much more often and in the background by validating the presence of the session’s private key on the user’s system and without forcing re-authentication.
DBSC allows for more aggressive detection rules for websites
It also allows website admins to be more aggressive with their detection rules for suspicious behavior. For example, if a cookie is suddenly used from a browser with a different User-Agent or a different IP address the website can respond with a request to revalidate the session through DBSC. A browser with a stolen cookie will obviously fail this check because it doesn’t have the private key to sign the challenge so the session can be killed.
According to the documentation, the refresh procedure works like this:
- For any request within an applicable scope, the browser checks if the necessary cookies exist. If they exist, continue as normal.
- If not, the browser defers such requests while performing more steps.
- The browser contacts the HTTP endpoint for the session, providing the session identifier and, if requested by the server, the necessary proof of possession of the associated private key.
- If the server is satisfied with the proof, it uses regular Set-Cookie headers to establish the necessary cookies with an appropriate Max-Age. The response can also include an updated set of instructions, e.g. if the server wishes to change which cookies are subject to this logic.
- If any requests were deferred in step 2, the browser now makes those requests including the updated set of cookies.
- The browser may choose to proactively refresh cookies that are about to expire if it predicts the user may soon need them. This is purely a latency optimization, and not required.
Anti-tracking protections and future support
Chrome engineers have designed the new mechanism with privacy protections in mind to prevent websites from tracking devices based on their private keys. This is why every session will have its own unique private-public key pair. Users can delete the keys at any time by clearing the site data and short-term cookies can only be refreshed while the user is browsing the website.
“DBSC doesn’t leak any meaningful information about the device beyond the fact that the browser thinks it can offer some type of secure storage,” the Chrome engineers said. “The only information sent to the server is the per-session public key which the server uses to certify proof of key possession later.”
The feature can be enabled in Chrome Beta by turning on the “enable-bound-session-credentials” under chrome://flags/ but for now will only work with Google accounts since it also needs server-side support.
However, Google said many other service providers and identity providers such as Okta, as well as browser vendors like Microsoft have expressed interest in the feature. Microsoft Edge is based on the Chromium engine and so are other browsers including Opera and Brave.
Under the current development timeline, the Chrome engineers behind this feature expect to be able to offer origin trials for all interested websites by the end of 2024.