Google has begun making Device Bound Session Credentials (DBSC) publicly available to Windows users on Chrome 146, after first announcing it in April 2024, with plans to expand it to macOS in a future Chrome release. The technology targets one of the most common session security problems: cookie theft, which allows attackers to access accounts without needing passwords.
Session theft typically occurs when a user unintentionally downloads malware. After it runs, the malware can extract existing cookies from the browser or wait for the user to log in to new accounts, then send the tokens to a server controlled by the attacker. Google says that information-stealing malware families, such as LummaC2, have become more sophisticated at collecting credentials.
These cookies are particularly dangerous because some remain valid for extended periods; attackers can use them to gain unauthorized access to accounts and then collect, trade, or sell them among criminal groups. Advanced malware, after gaining access to a device, can also read the files and memory in which browsers store authentication cookies. Google therefore believes there is no reliable way to prevent cookie extraction through software alone, regardless of the operating system.
Binding the Session to a Key That Never Leaves the Device
DBSC changes this model by cryptographically binding an authentication session to a specific device. The technology uses hardware-backed security modules, such as the TPM in Windows and the Secure Enclave in macOS, to generate a unique public-private key pair. The private key cannot be exported from the device.
The server issues new, short-lived cookies only after Chrome proves that it possesses the private key associated with the session. Since the attacker cannot steal this key, any cookies extracted will soon expire and become useless for accessing accounts. Google says it has observed a significant reduction in session theft involving DBSC-protected sessions since an early version of the protocol was introduced during the past year.
Sites, both large and small, can adopt hardware-bound sessions by adding dedicated registration and refresh endpoints to their back-end systems while maintaining compatibility with their existing front ends. The browser handles the complex cryptographic operations and cookie rotation in the background, while the web application continues to use standard cookies to access its services.
Protecting Sessions Without Tracking Users
DBSC was designed with privacy in mind. Each session is based on a separate key, preventing sites from using these credentials to link user activity across different sessions or across multiple sites on the same device. The protocol also does not send device identifiers or attestation data to the server, except for the session-specific public key needed to prove possession of the private key.
According to Google, this limited information exchange reduces the risk of using the technology for cross-site tracking or to build a device fingerprint.
An Open Standard Under Continued Development
DBSC was designed from the outset as an open web standard through the W3C process and with the adoption of the Web Application Security Working Group. Google collaborated with Microsoft on the standard’s design, while numerous web platforms, including Okta, participated in two Origin Trials during the past year and provided feedback based on testing and use.
Google provides developers with an implementation guide, along with the protocol specifications, a GitHub repository, and a page for reporting bugs or suggesting features.
Future development areas include:
- Securing federated identity: Expanding DBSC to support linking across different assets, so that the relying party’s session remains bound to the original device key used with the identity provider throughout the single sign-on process.
- Advanced enrollment capabilities: Binding sessions to preexisting trusted key material, such as mTLS certificates or hardware security keys, instead of generating a new key at sign-in.
- Broader device support: Exploring the addition of software-based keys to protect devices that do not include dedicated security hardware.