Cookie theft is one of those attacks that sounds unsophisticated but is genuinely hard to defend against. An infostealer like Redline or Raccoon Stealer exfiltrates your browser’s cookie database, hands the session tokens to an attacker, and the attacker imports them into their own browser. No credentials needed. No MFA to bypass. The stolen cookies are functionally identical to the original ones, and the server has no way to tell the difference.
Chrome 145’s Device Bound Session Credentials (DBSC) is Google’s structural answer to this, and the Windows announcement marks a significant milestone. The idea is straightforward: bind session credentials to the device’s hardware so that stealing the cookie without stealing the device becomes useless.
Why Existing Defenses Don’t Help
The standard cookie attributes (HttpOnly, Secure, SameSite) do real work, but they don’t address the infostealer threat at all. HttpOnly blocks JavaScript from reading a cookie, but an infostealer isn’t running as JavaScript. It’s a native process with access to the file system. On Windows, Chrome’s cookie database lives at %LocalAppData%\Google\Chrome\User Data\Default\Network\Cookies, encrypted with DPAPI (Data Protection API). DPAPI encrypts with keys tied to the Windows user account, and an infostealer running as that same user can decrypt the database without any special privileges.
SameSite helps with CSRF but has nothing to say about a cookie that’s been extracted from disk and replayed from a different machine.
Token Binding (RFC 8471) tried to solve a related problem at the TLS layer, binding tokens to the TLS connection itself. It died largely because middlebox infrastructure (load balancers, TLS terminators) couldn’t propagate the binding information correctly, and the deployment complexity was prohibitive. DBSC avoids this by operating at the application layer instead of the transport layer.
Mutual TLS is another option with similar properties, but it requires certificate management infrastructure on both sides and presents significant UX friction. It works well in enterprise settings with managed device fleets but isn’t viable as a general-purpose web authentication layer.
What DBSC Actually Does
DBSC uses asymmetric cryptography with the private key stored in a hardware-backed secure enclave. On Windows, this means the Trusted Platform Module (TPM 2.0). The key is created inside the TPM and never exported, so an infostealer that copies every file off the machine still can’t retrieve the private key.
The registration flow starts when a server includes a Sec-Session-Registration header in an HTTP response. This header specifies a registration_endpoint where the browser should post the public key, a challenge value, which cookies should be covered by the session binding, and key algorithm requirements (typically P-256 ECDSA).
Chrome generates the key pair (private key stays in the TPM), constructs a signed registration JWT, and POSTs it to the registration_endpoint. The server stores the public key associated with this session.
From this point, the session operates on a periodic refresh model. The server issues short-lived session cookies alongside the longer-lived account cookies. When a short-lived cookie expires, the browser needs to refresh it. The refresh endpoint issues a challenge, and the browser proves possession of the TPM-bound private key by signing the challenge. If the proof is valid, the server issues a new short-lived cookie.
This is the critical structural insight: the long-lived session isn’t stored in a cookie that can be stolen and replayed. It’s represented by a private key that can’t leave the hardware. Stolen cookies expire. Without the key, the attacker can’t refresh them.
The Windows-Specific Machinery
Chrome’s Windows integration for DBSC uses the Windows Platform Crypto Provider, which wraps TPM 2.0 operations through the Windows CNG (Cryptography Next Generation) API. Chrome calls NCryptCreatePersistedKey and related CNG functions to generate and use TPM-resident keys.
One important constraint: not all Windows machines have TPM 2.0. Windows 11 requires it, but Windows 10 deployments vary. On machines without TPM 2.0, Chrome can fall back to software-backed keys using DPAPI, which provides weaker guarantees but still represents an improvement over the current state where cookies are simply tied to the user account and accessible to any process running as that user.
Chrome also has to handle key lifecycle. TPM keys are persistent, but sessions end and browsers get reinstalled. The WICG DBSC proposal accounts for this by treating the key as a session-scoped resource: when a user signs out, the key should be deleted. Chrome owns that lifecycle management, which is a non-trivial operational concern that the spec leaves to the browser implementer.
Server-Side Requirements
DBSC is opt-in from the server’s perspective, which is both a feature and a limitation. Sites that implement DBSC support get the protection; sites that don’t are unaffected. This is fundamentally different from a transport-layer defense that would apply universally.
Implementing DBSC on the server requires sending the Sec-Session-Registration header on appropriate responses, providing a registration endpoint that accepts and stores public keys, issuing short-lived refresh tokens alongside session cookies, implementing a challenge-response endpoint for session refresh, and verifying ECDSA signatures during the refresh flow.
The verification side is standard JWT work. The signed refresh proof is a JSON Web Signature (JWS) using the registered public key, with a body containing the challenge and the registration endpoint URL to prevent cross-site replay. Server libraries will handle most of this once implementations mature, but it’s not zero work.
Google has been running DBSC in production on Google Accounts as part of the origin trial that preceded the Chrome 145 announcement. That gives them real-world data on the performance cost of the periodic refresh flow, which appears to be minimal in practice since refreshes happen at expiration boundaries rather than on every request.
What DBSC Doesn’t Protect Against
The threat model is specifically cookie exfiltration followed by use on a different device. DBSC doesn’t help when the attacker has persistent interactive access to the victim’s machine, because then they can drive Chrome directly. An attacker with remote code execution can make authenticated requests through existing browser interfaces without ever exporting a cookie file.
DBSC also doesn’t address phishing. If a user hands their credentials to an attacker who authenticates in real time from a different device, the session that gets established is on the attacker’s device and will be properly bound there.
It’s also not a privacy technology. The TPM-backed key is a per-session identifier that gets registered with the server. DBSC explicitly restricts key scope to prevent cross-site tracking: keys are associated with a single session registration rather than shared across sites. But the server still knows, with high confidence, whether a given request comes from the same device as the original authentication.
Where This Lands
The practical impact of DBSC depends heavily on adoption. Google can deploy this across its own services immediately, which covers a significant fraction of high-value sessions on the web. For everyone else, adoption depends on server-side implementation work, and that takes time.
The WICG proposal is still working through standardization, which means the header names and wire format could shift before things settle. Building production implementations now carries some risk of needing to track spec evolution.
The attack category DBSC addresses, infostealer malware selling session cookies in bulk, is genuinely widespread. Threat intelligence reports regularly cover large-scale markets for stolen session tokens. Browser-level defenses that make stolen cookies useless on other devices directly undercut the economics of that market.
The hardware angle is what makes this different from previous attempts at the same problem. Software-only defenses can be circumvented by software-only attackers who have the right level of access. Grounding the defense in TPM hardware raises the attack cost substantially. That’s the meaningful advancement here, not the protocol design, which is relatively straightforward, but the decision to make hardware attestation a first-class component of the browser session model.