Short-Lived Cookies and Hardware Keys: How Device Bound Session Credentials Rethinks Session Security

For most of the web’s history, a stolen session cookie was game over. Grab the bytes, replay them from anywhere, and you’re in. Every HttpOnly, Secure, and SameSite flag in the world couldn’t change that because those attributes govern how cookies travel over the network, not what happens when malware reads them directly off disk.

Google’s Device Bound Session Credentials (DBSC) is the most serious attempt yet to close that gap, and it does so by changing the fundamental nature of what a session proves: not just “this browser received a cookie at some point,” but “this specific device still holds a private key that has never left its hardware.”

The Infostealer Problem

Chrome stores cookies in a SQLite database on disk. On Windows, the path is typically %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies. The values are encrypted with DPAPI, but that encryption is scoped to the current user, which means any process running as that user can decrypt them. Infostealers, a category of malware that has become remarkably commoditized, do exactly this. They dump the cookie database, decrypt the values, and ship them off to an attacker who can then replay those cookies from any machine.

The attack bypasses multi-factor authentication entirely. By the time the cookies are stolen, the user already completed their MFA challenge during login. The session is live. No second factor is required to use it.

This isn’t a hypothetical. Google’s own security team has documented that cookie theft via malware is one of the primary vectors used in account takeover campaigns. The traditional response has been to shorten session lifetimes and monitor for anomalous access patterns, but both approaches have real limits: short sessions annoy users, and behavioral detection is imprecise.

What DBSC Actually Does

The core idea is straightforward: bind each session to a cryptographic key that lives in hardware and cannot be exported. When a server wants to establish a DBSC-protected session, the browser generates an asymmetric key pair. The private key gets stored in the device’s Trusted Platform Module (TPM) or equivalent secure enclave. The public key gets sent to the server. From that point, the browser must periodically prove possession of the private key to keep the session alive.

The session cookie issued by the server is intentionally short-lived, typically on the order of minutes rather than days. Before it expires, the browser automatically contacts a refresh endpoint defined by the server, signs a challenge with the hardware-bound private key, and exchanges that proof for a new short-lived cookie. A stolen cookie expires quickly, and refreshing it requires the hardware key, which an attacker on another machine simply does not have.

The WICG specification defines the HTTP-level protocol for this exchange. Servers signal DBSC support via a Sec-Session-Registration response header, which points to a registration endpoint. The browser POSTs the generated public key to that endpoint during session initialization. Subsequent refreshes use a signed proof-of-possession token, structured as a signed JWT, against a separate refresh endpoint.

HTTP/1.1 200 OK
Sec-Session-Registration: path="/session/register"; challenge="abc123"
Set-Cookie: session=<short-lived-token>; Max-Age=300; Secure; HttpOnly

The browser then POSTs to /session/register with the public key and a signature over the challenge. The server stores the public key, associates it with the session, and from this point forward treats the session as device-bound.

Key Storage Across Platforms

The strength of the binding depends heavily on where the private key lives. On Windows, DBSC uses the Cryptography API: Next Generation (CNG) with TPM-backed keys when available. The key is marked as non-exportable at the OS level, meaning no software call can retrieve the raw key material. On macOS, the Secure Enclave via the Security framework provides equivalent protection. Linux support involves various TPM 2.0 backends depending on the distribution.

When no hardware root of trust is available, the browser falls back to a software-protected key. This is weaker since determined attackers with OS-level access could theoretically extract it, but it still raises the bar considerably compared to raw cookie theft: an attacker now needs to extract a key rather than just copy a cookie value, and the techniques for doing so are less commoditized.

Chrome’s implementation uses the operating system’s key storage APIs rather than managing TPM interaction directly, which means the security properties vary by platform but benefit from whatever hardening the OS provides, including lockout policies and secure boot integration.

The Session Refresh Loop

The refresh flow is where the protocol’s security properties actually live. When the session cookie is approaching expiration, the browser sends a request to the server’s designated refresh endpoint. That request includes a signed JWT containing:

• The session identifier
• A timestamp (to prevent replay)
• A server-supplied nonce (to prevent replay across challenges)
• A signature over the above, created with the device-bound private key

The server verifies the signature against the stored public key. If it matches, the server issues a new short-lived cookie. If the session cookie was stolen and is being replayed from another device, the attacker cannot produce a valid signature because they do not have the private key. Their session cookie simply expires.

This design has an important property: the verification is entirely server-side and uses standard asymmetric cryptography. Servers do not need to trust any particular TPM vendor or attestation chain. They just verify an ECDSA or RSA signature over a well-defined payload. The complexity of hardware attestation is an optional layer on top, not a requirement for baseline protection.

Relationship to WebAuthn and Passkeys

It is worth being precise about where DBSC fits relative to passkeys and WebAuthn, since all three involve device-bound cryptographic keys used in browser-server interactions.

WebAuthn and passkeys are authentication mechanisms. They prove identity at login time and typically require a user gesture (biometric verification, PIN entry, or physical key tap). Each authentication ceremony is user-visible and intentional.

DBSC is a session continuity mechanism. It proves that the device that originally authenticated is still the device making requests, without requiring any further user interaction. The refresh loop runs entirely in the background. Users do not see it.

Put differently, passkeys solve the authentication problem; DBSC solves what happens after authentication succeeds and a session cookie is issued. A site can use passkeys for login and DBSC for the resulting session, layering protection at both points. The two mechanisms are complementary, not alternatives.

Server-Side Implementation Requirements

DBSC is not purely a browser-side feature. Servers must implement the registration and refresh endpoints, store public keys, verify signatures, and issue appropriately short-lived cookies. For large deployments, this is non-trivial.

The verification step requires a standard JOSE/JWS library, which exists in every major server language. The storage requirement is one public key per active session, which is comparable in size to storing a session token. The refresh endpoint must be low-latency since it sits in the critical path of keeping sessions alive. Rate limiting and abuse handling on the refresh endpoint requires thought, since a flood of refresh requests could be used to probe server behavior.

CDNs and reverse proxies introduce additional complexity. If cookie refresh happens at the edge, the edge layer needs access to public key storage, or must proxy refresh requests to an origin that does. Services using centralized session management are better positioned than those with distributed session stores.

What DBSC Does Not Protect Against

DBSC is designed specifically for the cookie exfiltration and remote replay scenario. It does not protect against malware that operates within the user’s browser session in real time: a browser extension or injected script that makes authenticated requests on behalf of the attacker while the session is live would still work, because those requests pass through the browser and its hardware-bound key normally.

It also does not prevent session fixation attacks where an attacker who controls network traffic can influence which session the user authenticates into, though that attack class is largely addressed by Secure cookies and HTTPS.

Shared devices present a different kind of complication. If multiple users share a device profile, they share the hardware key, which undermines the per-user binding. Enterprise deployments with shared kiosk machines or VDI environments may need policy exceptions or alternative approaches.

Where Things Stand

Chrome has been running DBSC through origin trials to let sites test the integration before broad rollout. The IETF httpbis working group is involved in standardizing the protocol, which matters for cross-browser adoption. Microsoft has indicated interest given the overlap with Windows security infrastructure, and Edge shares Chrome’s engine, making implementation more tractable.

The proposal is a meaningful advance on a problem that the existing cookie security model was never designed to address. Session tokens have always been bearer credentials: whoever has them wins. Device binding converts them into something closer to a proof of device possession, which is a different and much stronger guarantee. The session refresh architecture is clean, the server requirements are reasonable, and the fallback to software keys preserves functionality on hardware that lacks a TPM.

The hard part, as with most web security improvements, is deployment. Sites must update their session infrastructure. Users on older hardware without TPMs get weaker protection. And the infostealer ecosystem will adapt, focusing more on real-time browser exploitation once static cookie theft stops working reliably.

But that last point is worth sitting with for a moment. Forcing attackers from passive, asynchronous cookie theft toward active, real-time browser compromise is a meaningful win. The latter is harder to automate, more detectable, and more constrained. That is the realistic goal of DBSC, and it is a reasonable one.