Binding Sessions to Hardware: What DBSC Gets Right Where Token Binding Failed

The problem with session cookies is not that they can be stolen. It is that stealing them is straightforwardly profitable, requires no privilege escalation, and completely sidesteps MFA. That combination has fueled an industrial-scale criminal ecosystem around InfoStealer malware, and it has resisted every defensive measure short of replacing cookies entirely.

Google’s recent post on Device Bound Session Credentials (DBSC) describes a proposal that is closer to actually solving this than anything attempted before. Understanding why requires a clear picture of where the attack actually lives, because that is precisely where DBSC intervenes.

Where the Attack Actually Lives

On Windows, Chrome stores cookies in a SQLite database at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies. The cookie values are encrypted with an AES key, which is itself encrypted by the Windows Data Protection API (DPAPI) and stored in the Local State JSON file in the same profile directory.

DPAPI is scoped to the current user. Any process running as that user can call CryptUnprotectData() to decrypt the AES key, then use it to decrypt every cookie in the database. No elevation required, no exploit involved, just standard Win32 API calls that any user-mode process can make.

InfoStealer malware families like Lumma, Raccoon, and RedLine have automated this entirely. They copy the SQLite file to a temp path to avoid Chrome’s file lock, decrypt the AES key via DPAPI, decrypt each cookie record, and exfiltrate the results. The attacker loads those cookies into their own browser. The server sees a valid session cookie and has no basis to reject it. MFA was completed by the victim at login time; the session cookie is the post-authentication token, and it proves nothing about which machine holds it.

HttpOnly prevents JavaScript from reading cookies via document.cookie, stopping XSS-based theft. Secure limits cookies to HTTPS. SameSite=Strict prevents cross-site request forgery. None of these attributes apply to an operating system process reading the cookie database directly from disk. They are browser-enforced restrictions, and malware has bypassed the browser entirely.

Chrome shipped “App-Bound Encryption” in Chrome 127 (mid-2024), which wraps the DPAPI-protected AES key in a second layer verified by a privileged Windows service that confirms the calling process is Chrome itself. This raises the bar: a stealer can no longer trivially call DPAPI from an arbitrary user-mode process. Malware authors responded quickly with COM elevation abuse and Chrome process injection. App-Bound Encryption is useful hardening, but it addresses key storage rather than session portability. A cookie that has already been decrypted remains a fully valid session token on any machine, indefinitely.

What DBSC Does

DBSC (a WICG proposal, currently in Chrome origin trial) introduces a cryptographic keypair generated on the client device, with the private key stored in the platform’s hardware security element: TPM on Windows via the CNG Key Storage Provider, Secure Enclave on macOS via SecKey/CryptoKit. The private key is marked non-exportable and does not leave the hardware.

The protocol operates at the HTTP layer through a set of Sec--prefixed headers. The Fetch specification designates Sec--prefixed headers as forbidden header names, meaning JavaScript cannot set or forge them from a web page context.

Registration works as follows. The server sends a Sec-Session-Registration header in a response, specifying a path endpoint and a challenge nonce:

Sec-Session-Registration: path="/dbsc/register"; challenge="<base64-nonce>"

The browser generates a keypair on the TPM, constructs a signed JWT containing the public key and the server’s challenge, and POSTs it to the registration endpoint via Sec-Session-Response. The server stores the public key, associating it with the session identifier.

After registration, the server issues a short-lived credential alongside the longer-lived session cookie. This short-lived credential expires in minutes. When it expires, the browser automatically contacts the registered endpoint, signs a fresh challenge with the TPM-bound private key, and obtains a new short-lived credential before continuing any blocked requests:

Sec-Session-Challenge: challenge="<new-nonce>"; id="<session-id>"

The browser responds with:

Sec-Session-Response: <signed-JWT-containing-new-challenge>

The server validates the signature against the stored public key. If validation passes, the session continues. If validation fails or cannot be completed (say, because the session cookie is being used on a different device without the corresponding private key), the server can refuse the credential refresh and terminate the session.

A stolen session cookie is now insufficient on its own. To pass periodic re-verification, the attacker also needs the private key, which is locked in the victim’s TPM. Exfiltrating a cookie no longer grants indefinite access; the session invalidates as soon as the short-lived credential expires and cannot be refreshed without the hardware key.

The Token Binding Lesson

This is not the first attempt to bind HTTP sessions to cryptographic keys. Token Binding (RFCs 8471-8473), developed roughly between 2016 and 2019, pursued the same goal by embedding a signed message in TLS handshake extensions. Tokens, including cookies and OAuth tokens, were associated with a TLS-layer keypair. A stolen token could not be replayed over a different TLS connection because the attacker would lack the private key.

Chrome removed Token Binding support in version 130 (late 2024). The reasons are instructive.

Token Binding was designed around TLS 1.2 extension points. TLS 1.3, which shipped in 2018, rearchitected the handshake, and the integration became complicated, particularly around 0-RTT and session resumption semantics. HTTP/2 and HTTP/3 further confused matters: Token Binding assumed a token mapped to a single TLS connection, but HTTP/2 multiplexes many requests over one connection, and HTTP/3 runs over QUIC rather than TCP.

The more fundamental problem was enterprise TLS inspection. Corporate environments commonly deploy TLS-terminating proxies that decrypt traffic for DLP or security scanning, then re-originate a new TLS connection to the destination server. The re-originated connection uses a different keypair. Token Binding broke completely in these environments, and enterprise environments are common precisely where session security matters most. Requiring simultaneous protocol changes at the TLS library, browser, and server layers proved too much coordination. Firefox never shipped it. Adoption reached near zero.

DBSC deliberately avoids every one of these failure modes. It operates at the HTTP application layer, not the TLS layer. A TLS inspection proxy passes HTTP headers through unchanged; the binding is to the device keypair, not to the TLS connection. No changes to TLS libraries are required, no connection semantics are disrupted, and HTTP/3 presents no new complications. The Sec- prefix prevents JavaScript forgery, providing the tamper resistance that TLS-layer integration would have given, through a mechanism that existing web infrastructure handles without modification.

How This Fits With WebAuthn and mTLS

DBSC and WebAuthn are complementary rather than competing. WebAuthn proves that a specific user authenticated at a specific moment using a hardware-backed credential, with an explicit user gesture such as a PIN or biometric. It addresses the login step. DBSC proves that the session has remained on the original device since login, without requiring any user interaction. It addresses the session lifecycle.

The intended security model combines both: WebAuthn (or passkeys) at login to verify user identity, DBSC throughout the session to prevent the session token from becoming a portable credential usable anywhere. The underlying hardware infrastructure overlaps: DBSC reuses the platform authenticator subsystem that WebAuthn already relies on, which is why Chrome’s TPM integration could be built on top of existing, audited code paths.

Mutual TLS with client certificates covers related ground in enterprise contexts. A device certificate provisioned via MDM is presented at the TLS layer and provides per-connection device identity verification. This works well for managed devices with an existing PKI infrastructure, server-to-server API calls, and zero-trust network access scenarios. It does not work for consumer web sessions at scale (no PKI, no certificate management infrastructure, poor browser UX for client cert prompts), and it suffers from the same TLS-proxy problem as Token Binding. mTLS and DBSC address different deployment contexts more than they compete.

Limitations Worth Stating Plainly

On systems without TPM hardware, DBSC falls back to software-backed keys stored in the browser profile. This still provides some protection against simple file-copy attacks on the cookie database, since the key is separate from the cookies, but it does not protect against malware with full profile-directory read access. The security guarantee on Linux systems without a hardware security element is substantially weaker, which covers a significant portion of developer workstations.

The “device” abstraction is also imperfect. DBSC ties the session to the keypair generated at registration time, not to the physical hardware in any attestable way unless the server explicitly requests TPM attestation, which the spec supports but does not require. A server that skips attestation cannot distinguish between a hardware-backed key and a software-backed one.

Browser support currently means Chrome. Firefox and Safari have not committed to implementations, and the spec is being driven primarily by Google through the WICG incubation process. The HTTP headers are moving toward IETF HTTPBIS standardization, which should bring broader vendor participation, but that process has its own timeline.

The Practical Impact

Google has been building server-side DBSC support into its own identity infrastructure, with accounts.google.com as an early intended adopter. Once DBSC ships to Chrome stable alongside Google accounts support, a large fraction of the InfoStealer market’s most valuable target becomes non-replayable on attacker machines. Lumma Stealer’s infrastructure takedown by Microsoft’s Digital Crimes Unit in May 2025 disrupted one major player, but the MaaS model ensures rapid recovery. Structural defenses at the protocol level are more durable than takedowns.

The WICG repository and Chrome Platform Status page are the authoritative sources for progress tracking. The feature has been in origin trial across multiple Chrome milestones, which typically precedes a stable launch by a few releases. The design is sound, the implementation reuses proven infrastructure, and it avoids the architectural mistakes that killed the previous attempt. Cookie theft has been a solved problem on the attacker side for years; DBSC is the first defense that addresses the actual mechanism without making deployment impractical.