v147 · security

Device Bound Session Credentials

A protocol that lets a site bind a user's session to a hardware-backed keypair on the device. Stolen session cookies are no longer enough to impersonate the user — the attacker would need the device's private key, which never leaves it.

concepts

  1. Protocol Walkthrough

    Step through a DBSC session: register a device key, get a session-bound short-lived cookie, present proof-of-possession on every refresh. Each card shows the HTTP request shape and the role of each header.

  2. Cookie replay attack lab

    Two side-by-side devices call the backend DBSC refresh endpoint. The legit device signs with its registered P-256 key; the attacker only has the copied cookie and fails backend signature verification.

  3. Cookie replay simulator

    The original self-contained visual simulation of replaying one stolen cookie from two browsers, restored alongside the newer backend-backed lab rather than replaced by it.

  4. Session Binding Flow

    Animated step-through of the full DBSC lifecycle — keypair generation, signed registration request, server binding, per-request proof-of-possession — plus an attack-resistance comparison showing why a stolen cookie fails without the device's private key.

  5. Binding Strength Demo

    Generates a P-256 keypair via SubtleCrypto, signs a challenge, and scores the binding strength against five threat models (cookie theft, network replay, MITM, device clone, malware). Shows which attacks DBSC stops and which require additional defences.

  6. Compatibility Lab

    Probes the cryptographic primitives that DBSC relies on — SubtleCrypto P-256 key generation and signing, WebAuthn/navigator.credentials, and secure context. Runs a live P-256 keypair generation + sign/verify cycle, mirroring the proof-of-possession step DBSC performs on every session refresh.

why it shipped

Session cookie theft is one of the most common ways accounts get hijacked on the web — malware on a user's machine grabs the cookie file, replays it from somewhere else, and the site has no way to tell. DBSC closes that hole by binding the session to a private key the device holds in secure storage (TPM, Secure Enclave, etc.). Each session refresh requires a proof-of-possession signed by that key. A stolen cookie copied to a different machine can no longer pass the proof-of-possession check, so the attacker can't reuse the session.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗