The takeaway: Chrome is beginning to use hardware-backed cryptographic keys to make stolen browser cookies harder to use. The feature, called device-bound session credentials, links an authenticated web session to the device where the user signed in.
The change targets a common method of account takeover. Attackers who obtain a browser session cookie can sometimes load it into another browser and gain access to an account without entering the victim's password or completing two-factor authentication. Device-bound session credentials are designed to stop that by requiring proof that the browser still has access to a private key stored on the original device.
Chrome creates that key during the session setup process and stores it in protected hardware. On Windows, that hardware is the Trusted Platform Module, or TPM. Apple devices use the Secure Enclave. The private key is kept inside that hardware rather than exposed to the operating system or browser.
A website that supports the system stores the matching public key. When Chrome needs to maintain or refresh a session, the site can require the browser to sign a challenge with the private key. A copied cookie alone would not be enough because the attacker would not have the key required to produce a valid response.
Scott Helme, a researcher and founder of Report URI who blogged about the protections, told Ars Technica that the TPM or Secure Enclave keeps the private key on the user's device, preventing an attacker from extracting it. An attacker may still steal a session cookie, he said, but cannot complete the cryptographic challenge needed to use that cookie without access to the protected key.
The technology is aimed at the growing problem of session theft. Stronger login systems, including passkeys and multifactor authentication, have reduced the value of a stolen password. But they do not necessarily protect an already authenticated browser session. Once a user has completed the sign-in process, a site generally places a session cookie in the browser so the user can move through the site without logging in again on every page.
That convenience creates an opening for malware and phishing operations. Infostealers can collect browser data, including cookies, from compromised devices. Adversary-in-the-middle attacks can also intercept authenticated sessions. In both cases, the attacker may be able to use the stolen cookie in a separate browser and act as the legitimate user for as long as the session remains valid.
Device-bound session credentials add another check to that process. The cookie remains part of the session, but it is no longer the only proof that the user is authorized. Chrome must also show that it holds the private key tied to that session. Google's implementation uses hardware-backed keys and short-lived cookies, with the browser handling the refresh process in the background.
For now, the feature has a limited rollout. It is supported in Chrome version 147 for Windows and version 150 for macOS, but only for a subset of users. A site also has to support device-bound sessions before Chrome can use the protection.
Users can check whether the feature is active through Chrome's developer tools. In the Application tab, Chrome will show "device-bound sessions" when the user is signed in to a compatible site and the protection has been enabled.
It is not yet clear whether other Chromium-based browsers will add support. Wider adoption will also depend on whether websites decide to build the server-side registration and session-refresh systems required for the feature.