Ddos 
An overview of the DBSC protocol showing the interaction between the browser and server | Image: Google
In a major escalation of the war against credential-harvesting malware, the Google Account Security team has officially moved Device Bound Session Credentials (DBSC) into public availability. Starting with the release of Chrome 146 for Windows, this new security standard aims to neutralize one of the most persistent threats in the modern digital landscape: session hijacking.
For years, the Achilles’ heel of web security has been the reliance on session cookies. While these digital tokens provide a convenient “stay logged in” experience, they have become a primary target for sophisticated infostealer malware families like LummaC2.
As the Google security team notes, “session theft typically occurs when a user inadvertently downloads malware onto their device”. Once active, this malware can “silently extract existing session cookies from the browser or wait for the user to log in to new accounts, before exfiltrating these tokens to an attacker-controlled server”.
Because these cookies often have extended lifetimes, hackers can use them to bypass both passwords and multi-factor authentication (MFA). Historically, defending against this has been a game of “catch-up,” relying on reactive heuristics to spot stolen credentials after the damage is done.
DBSC shifts the paradigm from reactive detection to proactive hardware-level prevention. Instead of allowing session cookies to exist as unprotected files on a disk, DBSC cryptographically binds authentication sessions to a specific physical device.
The technical “vault” for this protection is the computer’s own security chip—the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS.
- Chrome uses these hardware modules to generate a unique public/private key pair that “cannot be exported from the machine”.
- The web server only issues new, short-lived session cookies if Chrome can prove it possesses the private key.
- Even if an attacker manages to exfiltrate a cookie, it becomes “worthless” the moment it is moved to another device, as they lack the hardware-bound private key required to maintain the session.
A core concern for Google during development was ensuring that device-level security didn’t come at the cost of user privacy. DBSC is designed to be “privacy-preserving” by utilizing distinct keys for every session. This architecture prevents websites from using DBSC credentials to “correlate a user’s activity across different sessions or sites on the same device”.
While Windows users on Chrome 146 are the first to receive this “shield,” Google plans to expand support to macOS in an upcoming release. Future iterations of the DBSC standard will focus on:
- Securing Federated Identity: Ensuring Single Sign-On (SSO) sessions remain bound to the device key throughout the entire federated login process.
- Advanced Registration: Allowing websites to integrate mTLS certificates or hardware security keys during the initial session creation.
- Software-Based Keys: Exploring protections for devices that lack dedicated secure hardware.
By turning the physical device itself into the ultimate credential, Google is aiming to make the multibillion-dollar infostealer market obsolete, one hardware-bound session at a time.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
