Google Rolls Out DBSC in Chrome 146 to Stop Session Cookie Theft
Google has officially shipped Device Bound Session Credentials (DBSC) as part of Chrome 146 for Windows, introducing a hardware-level defense against the increasingly prevalent threat of infostealer malware targeting session cookies. A corresponding rollout for macOS users is expected in a future Chrome release, though no specific version has yet been announced.
The technology was first publicly announced in 2024 and has now reached general availability for Windows users, marking a significant shift in how browsers handle session authentication security.
How DBSC Works: Binding Sessions to Hardware
At its core, DBSC functions by cryptographically binding a user's active browser session to the specific device they are using. On Windows machines, this relies on the Trusted Platform Module (TPM), while macOS will leverage the Secure Enclave when support arrives.
The binding is accomplished through unique public/private key pairs generated directly by the device's security chip. Because these keys are created and stored within the hardware itself, they cannot be exported from the machine under any circumstances. This architectural constraint is what makes the protection effective against even sophisticated theft attempts.
According to Google's announcement, the mechanism works as follows:
- A session is established between Chrome and the server, backed by a hardware-bound key pair.
- Short-lived session cookies are issued on an ongoing basis, but their renewal requires Chrome to cryptographically prove it still possesses the private key.
- If an attacker exfiltrates a session cookie, they cannot renew it because they lack access to the private key, which never leaves the victim's machine.
Google summarized the requirement clearly:
"The issuance of new short-lived session cookies is contingent upon Chrome proving possession of the corresponding private key to the server."
Without that proof of possession, any stolen session cookie expires almost immediately, rendering it worthless to a threat actor.
Why Session Cookies Are a Prime Target for Infostealers
Session cookies serve as authentication tokens, typically with longer validity windows than standard login sessions. They are generated server-side after a user authenticates with a username and password, and the server subsequently uses these cookies to identify returning users without requiring repeated credential entry.
This convenience makes them extremely valuable to cybercriminals. Infostealer malware is specifically designed to locate and extract these cookies from local files and browser memory. Google pointed out that families such as LummaC2 "have become increasingly sophisticated at harvesting these credentials," enabling attackers to hijack accounts without ever knowing the victim's password.
Google acknowledged the fundamental challenge in its announcement:
"Crucially, once sophisticated malware has gained access to a machine, it can read the local files and memory where browsers store authentication cookies. As a result, there is no reliable way to prevent cookie exfiltration using software alone on any operating system."
DBSC sidesteps this limitation not by preventing theft of the cookie itself, but by making the stolen cookie non-functional without the hardware-bound key.
Privacy Protections Built Into the Protocol
Google emphasized that DBSC was designed with user privacy as a primary consideration, not merely an afterthought. Key privacy properties include:
- Per-session unique keys: Each session is backed by a distinct key, preventing websites from correlating a user's activity across multiple sessions or different sites on the same device.
- Minimal data exchange: The protocol only requires sharing the per-session public key needed to verify proof of possession. It does not transmit or expose any device identifiers.
These properties ensure that the hardware-binding mechanism does not inadvertently become a tracking vector.
Industry Collaboration and Real-World Testing
DBSC is not a purely unilateral Google initiative. The company partnered with Microsoft in developing DBSC as an open web standard, and received input from numerous industry stakeholders involved in web security. Specifications are published on the World Wide Web Consortium (W3C) website, and a detailed explainer is available on GitHub.
Before the Chrome 146 launch, Google spent a year testing an early version of DBSC in collaboration with multiple web platforms, including identity provider Okta. During that testing period, Google observed a notable decline in session theft events, lending empirical weight to the protocol's effectiveness.
What Website Operators Need to Do
Adoption of DBSC does not require websites to overhaul their existing infrastructure. Operators can upgrade to hardware-bound sessions by adding dedicated registration and refresh endpoints to their backend systems. Google has confirmed this approach maintains compatibility with existing frontend implementations, lowering the barrier to adoption.
Web developers seeking implementation guidance can refer to Google's official DBSC implementation guide, the W3C specifications, and the GitHub explainer for technical details on integrating the protocol into their services.
Looking Ahead
With Chrome 146 delivering DBSC to Windows users and macOS support on the horizon, Google is making a tangible step toward neutralizing one of the most effective techniques in the modern infostealer playbook. The combination of hardware-level key storage, short-lived cookies, and open standardization positions DBSC as a meaningful long-term solution to session hijacking — one that the broader web ecosystem can adopt regardless of browser or platform.
Source: BleepingComputer