Google has rolled out Device Bound Session Credentials (DBSC) protection in Chrome 146 for Windows, designed to block info-stealing malware from harvesting session cookies.
macOS users will benefit from this security feature in a future Chrome release that has yet to be announced.
The new protection has been announced in 2024, and it works by cryptographically linking a user’s session to their specific hardware, such as a computer’s security chip – the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS.
Since the unique public/private keys for encrypting and decrypting sensitive data are generated by the security chip, they cannot be exported from the machine.
This prevents the attacker from using stolen session data because the unique private key protecting it cannot be exported from the machine.
“The issuance of new short-lived session cookies is contingent upon Chrome proving possession of the corresponding private key to the server,” Google says in an announcement today.
Without this key, any exfiltrated session cookie expires and becomes useless to an attacker almost immediately.
source: Google
A session cookie acts as an authentication token, typically with a longer validity time, and is created server-side based on your username and password.
The server uses the session cookie for identification and sends it to the browser, which presents it when you access the online service.
Because they allow authenticating to a server without providing credentials, threat actors use specialized malware called infostealer to collect session cookies.
Google says that multiple infostealer malware families, like LummaC2, “have become increasingly sophisticated at harvesting these credentials,” allowing hackers to gain access to users’ accounts.
“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” – Google
The DBSC protocol was built to be private by design, with each session being backed by a distinct key. This prevents websites from correlating user activity across multiple sessions or sites on the same device.
Additionally, the protocol enables minimal information exchange that requires only the per-session public key necessary to certify proof of possession, and does not leak device identifiers.
In a year of testing an early version of DBSC in partnership with multiple web platforms, including Okta, Google observed a notable decline in session theft events.
Google partnered with Microsoft for developing the DBSC protocol as an open web standard and received input “from many in the industry that are responsible for web security.”
Websites can upgrade to the more secure, hardware-bound sessions by adding a dedicated registration and refresh endpoints to their backends without sacrificing compatibility with the existing frontend.
Web developers can turn to Google’s guide for DBSC implementation details. Specifications are available on the World Wide Web Consortium (W3C) website, while an explainer can be found on GitHub.
Automated Pentesting Covers Only 1 of 6 Surfaces.
Automated pentesting proves the path exists. BAS proves whether your controls stop it. Most teams run one without the other.
This whitepaper maps six validation surfaces, shows where coverage ends, and provides practitioners with three diagnostic questions for any tool evaluation.
Related Articles:
Microsoft fixes bug that blocked Google Chrome from launching
Microsoft suspends dev accounts for high-profile open source projects
Microsoft rolls out fix for broken Windows Start Menu search
Why Simple Breach Monitoring is No Longer Enough
Disgruntled researcher leaks “BlueHammer” Windows zero-day exploit