Binding Sessions to Hardware: What DBSC Solves That Cookie Flags Never Could

The threat model that existing cookie security attributes address has never included infostealer malware. HttpOnly blocks JavaScript from reading cookies, stopping XSS-based theft. SameSite prevents cross-site request forgery. The Secure flag ensures cookies only travel over TLS. All of these protections operate at the boundary between your application and network traffic, or between your application and the browser’s script execution environment.

Inforstealer malware doesn’t cross any of those boundaries. It runs on the victim’s operating system, reads cookie files from disk after the browser has already decrypted them, and exfiltrates the plaintext session tokens. The browser’s security attributes never had an opinion about what happens to cookies once they’re sitting in a SQLite database on the filesystem. Device Bound Session Credentials is the first serious browser-level attempt to make that attack category structurally unworkable.

The Threat Model in Concrete Terms

The infostealer ecosystem has industrialized cookie theft to a remarkable degree. Tools like LummaC2, Redline, and Vidar are sold as malware-as-a-service, exfiltrate Chrome’s cookie store (a SQLite file at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies), and send the contents to a command-and-control server within seconds of execution. The resulting credential dumps are sold in bulk on darknet marketplaces.

Chrome’s cookies are encrypted at rest using the Windows Data Protection API (DPAPI), keyed to the current user. Malware running as the victim’s user account can call CryptUnprotectData with the user’s context and decrypt every cookie in the store. Chrome added App-Bound Encryption in 2024, which uses a Windows SYSTEM-level service as an encryption oracle to make decryption harder from user-space. It raised the bar, but malware adapted.

Google documented the scale of the YouTube creator account takeover campaign: over 15,000 accounts compromised in a coordinated operation, all through cookie theft, all bypassing MFA because the attacker had valid post-authentication session tokens. The authentication step had already happened; WebAuthn and hardware security keys have no say over what happens to the cookie issued afterward.

DBSC doesn’t try to prevent cookie files from being stolen. It makes stolen cookies expire quickly and unrefreshable on any device but the one that generated the session.

How the Protocol Works

The core mechanic is straightforward: the browser generates an asymmetric key pair per session, stores the private key in hardware-backed storage (TPM on Windows and Linux, Secure Enclave on macOS), and proves possession of that key to the server on a regular interval. Short-lived session cookies expire before an attacker can make meaningful use of them; long-term persistence requires the ability to produce valid signatures, which requires the private key, which never leaves the device.

The flow starts with a server response header:

Sec-Session-Registration: registration-endpoint="/.well-known/dbsc/register";
                           challenge="<base64-nonce>"

The browser generates a new ECDSA P-256 key pair, binds the private key to the platform’s hardware security module, and POSTs a registration payload to the endpoint. That payload includes the public key in JWK format and a signed proof-of-possession JWT:

{
  "header": { "alg": "ES256", "typ": "JWT" },
  "payload": {
    "aud": "https://example.com/.well-known/dbsc/register",
    "jti": "<server-nonce>",
    "iat": 1712345678,
    "key": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
  }
}

The server validates the JWT, stores the public key against the session, and returns a configuration object:

{
  "session_identifier": "sess_abc123",
  "refresh_url": "/session/refresh",
  "credentials": [{
    "type": "cookie",
    "name": "SESSION",
    "attributes": "Secure; HttpOnly; SameSite=Strict; Max-Age=300"
  }]
}

The Max-Age=300 is the critical element. The session cookie lives for five minutes. Before it expires, the browser automatically hits the refresh endpoint with a freshly signed JWT. The server checks the signature against the registered public key, and if valid, issues a new five-minute cookie. The whole refresh cycle happens in the background, invisible to the user.

An attacker who steals the cookie has at most five minutes before it expires, and they cannot hit the refresh endpoint themselves because they don’t have the private key.

What Hardware-Bound Actually Means Per Platform

The security guarantee varies by platform, and the WICG explainer is honest about that.

On Windows, private keys are stored using DPAPI-NG (the successor to DPAPI) with TPM-backed storage, or via Windows Hello credentials. TPMs implement key storage in a way that prevents private key material from being exported. Even a process running with Administrator privileges cannot extract the raw key bytes from the TPM; cryptographic operations are performed inside the chip.

On macOS, the Secure Enclave handles key storage through the LocalAuthentication framework. The private key never leaves the coprocessor. CryptoKit provides the interface Chrome uses to interact with it.

On Linux, the story is more varied. TPM 2.0 via tpm2-tools and libp11 covers the hardware path, but device support is less uniform than on Windows and macOS.

On devices without hardware security modules (older hardware, VMs, some Linux configurations), DBSC falls back to software-only key storage. This still meaningfully raises the bar over plain cookie files, since the attacker now needs to extract a key from browser process memory rather than just reading a database file, but it removes the hardware guarantee.

Why Prior Attempts Failed or Fell Short

Token Binding (RFC 8471) tried to solve a related problem in 2018 by binding tokens to the TLS layer. The idea was to embed a proof-of-possession into the TLS session itself so that tokens stolen from transport couldn’t be replayed against a different connection. It collapsed under the weight of enterprise TLS-terminating proxies and CDN middleboxes. Any infrastructure that terminates and re-originates TLS connections breaks Token Binding entirely, and that describes a substantial fraction of corporate network deployments. Adoption never happened; the working group quietly wound down.

DPoP (RFC 9449) applies proof-of-possession to OAuth 2.0 access tokens. It’s well-designed and seeing real adoption in OAuth-heavy contexts. The limitation for general web sessions is that DPoP requires an OAuth infrastructure. It doesn’t help for cookie-based sessions that don’t go through an authorization server, which is still the majority of web authentication.

Chrome’s App-Bound Encryption from 2024 is a pragmatic defense-in-depth measure, not a protocol-level fix. It makes the Chrome cookie store harder to decrypt from user-space by routing decryption through a SYSTEM-level service that validates the requesting process. Malware that elevates privileges, or hooks into the Chrome process directly, bypasses it. It buys time against commodity malware but doesn’t change the underlying architecture.

DBSC addresses the structural problem: the server has no way to verify that the entity presenting a session cookie is the same device that originally authenticated. DBSC adds that verification without requiring TLS-layer changes or OAuth infrastructure.

Server Implementation Requirements

Supporting DBSC requires two new endpoints and a shift in how session cookies are configured.

The registration endpoint (conventionally POST /.well-known/dbsc/register, though the path is configurable via the response header) receives the browser’s public key and signed JWT, validates the proof-of-possession signature using any standard ES256 JWT library, stores the public key associated with the session, and returns the session configuration JSON. The refresh endpoint receives a new signed JWT on each automatic renewal, verifies the signature against the stored public key, checks that the JWT audience and nonce are correct, and issues a fresh short-lived cookie. Standard JWT verification libraries handle the ES256 check; there’s no DBSC-specific server library required.

Session cookies get a short Max-Age, typically 300 to 600 seconds. The browser handles renewal transparently, so the user experience is unchanged.

Backwards compatibility is additive. Browsers without DBSC support ignore the Sec-Session-Registration header entirely. A server can issue long-lived cookies to non-DBSC browsers while issuing short-lived, hardware-bound cookies to DBSC-supporting ones, degrading gracefully without conditional logic in most application code.

Privacy Considerations the Spec Gets Right

A naive implementation of hardware-bound keys would create a stable device identifier: if the same public key were used across all sessions for all sites, servers could link sessions across sites to the same physical device. That would be a significant privacy regression.

The DBSC spec mandates per-session, per-origin key pairs. A new key is generated for every new DBSC session, and keys for different origins are necessarily different. This prevents cross-site correlation based on key identity. The privacy model is explicitly designed so that DBSC cannot be used as a device fingerprinting mechanism, which separates it from earlier device-binding proposals that were criticized on exactly those grounds.

Browser Support and Where Things Stand

Chrome has been running an Origin Trial since mid-2024, tracked at the Chrome Status entry. Google’s own accounts (Gmail, Workspace) have been in the pilot, representing the first large-scale real-world deployment. Microsoft has been involved in the spec work given Edge’s shared Chromium base and Windows’ strong TPM story; the WICG repository shows multi-vendor participation in the issue tracker. Firefox and Safari have not announced implementations, which limits universal applicability for now, though Chrome’s market share means meaningful coverage even without cross-browser uniformity.

Limitations Worth Keeping in Mind

DBSC does not protect against malware that runs persistently on the victim device and intercepts refresh requests in real time. If an attacker’s code is still executing when the refresh cycle fires, it can proxy the legitimate refresh and obtain valid cookies. This is a significantly harder attack than simple cookie exfiltration; it requires continued execution on the victim machine and coordination with the attacker’s infrastructure. But it is not impossible, and DBSC should be treated as one layer in a defense-in-depth stack.

The short-lived cookie model also creates resilience requirements for the refresh endpoint. A server outage or network error during a refresh attempt can log the user out. Applications need reliable, low-latency refresh endpoints, and the retry logic for transient failures is worth thinking through carefully before deployment.

The combination of DBSC with existing session security practices, rate-limited refresh endpoints, and anomaly detection on refresh patterns gives defenders a toolkit that simply didn’t exist before. The protocol won’t make infostealer campaigns unprofitable overnight, but it raises the cost of post-theft exploitation substantially. For a threat category that currently operates at industrial scale, that is a concrete improvement over a decade of cookie attribute additions that were never designed for this problem.