Seonglae ChoDBSC
DBSC binds a session cookie to a private key generated in the device’s TPM or Secure Enclave, so even if the cookie is stolen, the session cannot be used on another device.
- If the DBSC state is stored together with the regular session blob, a race condition can cause the binding to disappear and silently downgrade authentication to a regular bearer-cookie model.
- During refresh, the cookie and challenge must be rotated every time. Because of real network latency, the system also needs overlap handling that briefly accepts the previous cookie. A bug that did not appear on localhost caused random logouts in production.
/dbsc/refreshmust return 401 because a 302 redirect can cause a Chrome tab to hang indefinitely.
- A challenge mismatch is not necessarily an attack; it can normally occur because of concurrent refreshes or retries. If the signature is valid, do not revoke the session. Instead, issue a new challenge and retry.
- In SAML/SSO flows, the initial DBSC registration POST can be sent without authentication because of
SameSite=Lax, so binding should happen on the next same-site navigation.
Everything I Learned Shipping Device Bound Session Credentials
We shipped Device Bound Session Credentials at Report URI, open-sourced the server-side implementation, and then discovered a long list of things the specification doesn't prepare you for. Some caused random logouts. One could deadlock a browser tab indefinitely. Two silently turned a device-bound session back into
https://scotthelme.co.uk/everything-i-learned-shipping-device-bound-session-credentials/
