Google developers have begun implementing Device Bound Session Credentials (DBSC) in Chrome , which should prevent infostealers from stealing session cookies. The protection is already available in Chrome 146 for Windows, and will be available for macOS in a future release.
Google announced the development of DBSC back in April 2024. The idea is to cryptographically bind a user's session to specific hardware—a TPM module in Windows or a Secure Enclave in macOS. A unique key pair is generated directly on the security chip; the private key cannot be extracted from the device, and without this, any stolen cookies become useless bytes.
A session cookie is essentially a long-lived authentication token that the server creates after entering a username and password. This is why such cookies have long been a coveted target for malware operators: they can be used to gain access to someone else's account without even a password. Google notes that families like LummaC2 are becoming increasingly sophisticated when it comes to harvesting such credentials.
DBSC was designed with privacy in mind: each session has its own key pair, preventing websites from linking user activity across sessions or resources on the same device. Only the public key for a specific session is transmitted to the server, without any device identifiers.
Google reports that during early testing of DBSC with Okta and other partners, they observed a significant reduction in session hijacking incidents.
To enable protection, websites simply add a couple of endpoints to the backend for session registration and refresh. No frontend redesign is required, and all web applications will continue to work with standard cookies.
Google described the implementation details in a separate developer guide , and the specifications were published on the W3C website .
The developers report that work is already underway to further develop DBSC. Plans include support for cross-origin bindings to secure federated authentication, as well as the ability to bind new sessions to existing trusted keys. In addition, the company is considering the option of working with software keys (for devices that do not have a separate secure chip).
Google announced the development of DBSC back in April 2024. The idea is to cryptographically bind a user's session to specific hardware—a TPM module in Windows or a Secure Enclave in macOS. A unique key pair is generated directly on the security chip; the private key cannot be extracted from the device, and without this, any stolen cookies become useless bytes.
| "New short-lived session cookies are issued only if Chrome can prove to the server that it owns the corresponding private key," Google explains. |
| "Once advanced malware gains access to a machine, it can read local files and memory where browsers store cookies. No software can prevent their theft, even on a single operating system," the company states. |
Google reports that during early testing of DBSC with Okta and other partners, they observed a significant reduction in session hijacking incidents.
To enable protection, websites simply add a couple of endpoints to the backend for session registration and refresh. No frontend redesign is required, and all web applications will continue to work with standard cookies.
Google described the implementation details in a separate developer guide , and the specifications were published on the W3C website .
The developers report that work is already underway to further develop DBSC. Plans include support for cross-origin bindings to secure federated authentication, as well as the ability to bind new sessions to existing trusted keys. In addition, the company is considering the option of working with software keys (for devices that do not have a separate secure chip).