Google has officially rolled out a new security feature for Windows users on Chrome 146 designed to block info-stealing malware from harvesting session cookies. Known as Device Bound Session Credentials (DBSC), this proactive security measure aims to disrupt the thriving market for stolen browser cookies by making exfiltrated data completely useless to attackers.
Initially announced in April 2024, the public availability of Device Bound Session Credentials fundamentally changes how web browsers defend against session hijacking. While Windows users are the first to receive this update, Google has confirmed that macOS users will benefit from the exact same security feature in an upcoming Chrome release.
How Device Bound Session Credentials Prevent Session Hijacking
Traditionally, mitigating session theft relied on reactive detection methods and complex abuse heuristics to identify stolen credentials after an attack occurred. Persistent threat actors could often circumvent these measures. Device Bound Session Credentials shift the paradigm from reactive detection to proactive prevention by cryptographically binding authentication sessions to a user’s specific device.
When a user authenticates, Chrome generates a unique public and private key pair. The issuance of new, short-lived session cookies relies entirely on the browser proving possession of the corresponding private key to the server. Because the private key cannot be exported from the machine, attackers who manage to exfiltrate the session cookie cannot authenticate without access to the user’s actual device. Without the private key, the stolen cookies expire almost immediately and become entirely useless.
The Role of Hardware Security Modules
To ensure the private keys remain secure, Device Bound Session Credentials rely on hardware-backed security modules built directly into modern computers. On Windows systems, this process utilizes the Trusted Platform Module (TPM). For Apple devices, the cryptographic keys will be secured using the macOS Secure Enclave.
By tying the session securely to the device’s physical hardware, Google ensures that the unique private key protecting the sensitive session data cannot be extracted, even if sophisticated malware gains access to local files and memory where authentication cookies are stored.
Why Cookie Theft Has Become a Major Security Threat
Session cookies act as authentication tokens created on the server side based on a user’s login credentials. Because they allow users to remain authenticated to a service without repeatedly providing a password, they typically have extended lifetimes.
Threat actors deploy specialized info-stealing malware, such as the LummaC2 family, to silently extract existing session cookies from a browser or wait for a user to log into new accounts. Hackers can then use these stolen cookies to gain unauthorized access to user accounts. This stolen access is frequently bundled, traded, or sold among malicious actors.
Because sophisticated malware can easily read the local files where browsers store cookies, Google noted that there is no reliable way to prevent cookie exfiltration using software alone on any operating system.
Real-World Consequences of Stolen Cookies
The threat of session hijacking is not merely theoretical. In 2023, the popular YouTube channel Linus Tech Tips suffered a high-profile breach due to this exact type of attack. An employee inadvertently opened a malicious PDF file that allowed malware to steal the employee’s browser cookies. Attackers then used those exfiltrated cookies to bypass login screens, access the company’s social media accounts, and post cryptocurrency scams. With Device Bound Session Credentials fully implemented, this specific attack vector would be completely blocked, as the stolen cookies would not function outside of the employee’s physical computer.
Privacy and Open Web Standards
While increasing security, Google built the Device Bound Session Credentials protocol to be private by design. Each individual web session is backed by a distinct cryptographic key. This separation prevents websites from correlating a user’s activity across multiple sessions or sites on the same device.
Furthermore, the protocol minimizes information exchange. It only requires the per-session public key necessary to prove possession, ensuring that it does not leak device identifiers or attestation data to the server. This prevents the security feature from being misused for cross-site tracking or device fingerprinting.
To ensure broad compatibility, Google partnered with Microsoft and engaged with the Web Application Security Working Group to develop the protocol as an open web standard through the W3C process. Over the past year, Google also conducted two Origin Trials, receiving essential feedback from web platforms like Okta. Web developers can now upgrade to hardware-bound sessions by adding dedicated registration and refresh endpoints to their backends without altering their existing front-end architecture.
Future Improvements for Enterprise Security
As the Device Bound Session Credentials standard evolves, Google plans to introduce advanced capabilities tailored for complex enterprise environments. Key areas of ongoing development include:
- Securing Federated Identity: Google is expanding the protocol to support cross-origin bindings for Single Sign-On (SSO) environments. This ensures that a relying party session remains bound to the original device key used by the Identity Provider, maintaining an unbroken chain of trust throughout the federated login process.
- Advanced Registration Capabilities: For environments requiring stricter security, Google is developing mechanisms to bind sessions to pre-existing trusted key material, such as mTLS certificates or hardware security keys, rather than generating new keys at sign-in.
- Broader Device Support: To protect devices that lack dedicated secure hardware, Google is actively exploring the addition of software-based keys.
