Google released Device Bound Session Credentials (DBSC) protection in Chrome 146 for Windows, designed to prevent information-stealing malware from harvesting session cookies.
macOS users will benefit from this security feature in the upcoming release of Chrome that is yet to be announced.
A new protection was announced in 2024, and it works by cryptographically linking the user’s session to his specific hardware, such as the computer’s security chip – the Trusted Platform Module (TPM) in Windows and the Secure Enclave in macOS.
Since different public/private keys for encrypting and decrypting sensitive data are generated by the security chip, they cannot be sent to the device.
This prevents an attacker from using stolen session data because the unique private key it protects cannot be sent to the machine.
“The issuance of new short-term cookies depends on Chrome proving that it has a compatible server private key,” Google said in an announcement today.
Without this key, any filtered session cookie expires and becomes useless to the attacker immediately.
source: Google
A session cookie acts as an authentication token, usually with a long authentication time, and is generated on the server side based on your username and password.
The server uses a session cookie to identify and send it to the browser, which it presents when you access the Internet service.
Because they allow authenticating to the server without providing credentials, threat actors use a special malware called infostealer to collect session cookies.
Google says that many families of infostealer malware, such as LummaC2, are “very advanced in obtaining these credentials,” allowing hackers to gain access to user accounts.
“Importantly, once malicious malware gains access to a machine, it can read local files and memory where browsers store authentication cookies. As a result, there is no reliable way to prevent cookie issuance using software alone on any operating system” – Google
The DBSC protocol is designed to be private by design, with each session supported by a unique key. This prevents websites from linking users’ activity across sessions or sites on the same device.
Additionally, the protocol enables minimal information exchange that only requires the one-time public key needed to verify management credentials, and does not leak device identifiers.
In a year of testing the first version of DBSC in partnership with several web platforms, including Okta, Google has seen a significant decrease in session theft events.
Google partnered with Microsoft to develop the DBSC protocol as an open web standard and received input “from many in the industry responsible for web security.”
Websites can upgrade to more secure, hardware-bound sessions by adding dedicated registration and update points to their backends without sacrificing compatibility with the existing frontend.
Web developers can refer to Google’s guide for DBSC usage details. Details are available on the World Wide Web Consortium (W3C) website, and the specifier can be found on GitHub.
Automatic logging proves that the path exists. BAS proves that your controls are stopping you. Many teams run without each other.
This white paper outlines six areas of validation, indicates where coverage ends, and provides clinicians with three diagnostic questions for any screening tool.
