Device Bound Session Credentials (DBSC)
What is DBSC?
Device Bound Session Credentials is a web standard that ties your logged-in session to the device you logged in on. Instead of relying on a session cookie alone, your browser generates a private key that is stored in your device's secure hardware — a TPM or secure element — and periodically proves to us that it still holds that key.
The private key cannot be copied off the device, even by software running on it. That is what makes the standard worth having: session cookie theft is one of the most common ways accounts are taken over, and it defeats two-factor authentication entirely because the attacker never has to log in. A stolen Report URI session cookie is useless on an attacker's machine, because they cannot produce the proof that goes with it.
Do I need to set anything up?
No. DBSC is negotiated between your browser and our servers automatically, with nothing to enable and nothing to configure. If your browser supports it, your session is bound; if it does not, you log in exactly as before.
DBSC is currently in open beta. During the beta we enable it for a small percentage of logins so we can watch its behaviour in production before turning it on for everyone, so you should not expect every session to be bound yet — and a session that is bound today may not be next time you log in. Sessions that are not selected are unaffected in every way.
Which browsers support it?
DBSC is supported in recent versions of Google Chrome. No other browser has shipped it yet, though the standard is being developed in the open at the W3C Web Application Security Working Group.
The feature also needs hardware key storage available to the browser. On a machine without it, Chrome will not register a bound session and you will simply log in as normal.
How it works
There are three moments worth understanding.
Registration happens when you log in. We send your browser a header asking it to start a bound session; the browser generates a key pair in hardware, keeps the private key, and sends us the public key signed as proof. From that point the session is bound to that device.
Refresh happens every few minutes in the background. We issue a short-lived cookie that expires after 5 minutes, and before it expires your browser silently proves it still holds the private key to get a fresh one. You will not see this happen — there is no prompt and no interruption.
Enforcement happens on every request. If a request arrives with a session that should be bound but cannot present the correct short-lived cookie, we end that session immediately rather than serving it. This is the step that makes a stolen cookie worthless.
Checking whether a session is bound
Head to the Settings page and click Manage Sessions in the Authentication section. The table lists every device and browser currently signed in to your account, and the Bound column tells you the DBSC state of each one:
| Icon | Meaning |
|---|---|
| Green tick | The session is bound to that device. |
| Grey cross | The session is not bound — either the browser does not support DBSC, or the session was not selected during the beta rollout. |
| Amber question mark | We could not determine the state. Reload the page; if it persists, get in touch. |
This is also the place to sign out a session you do not recognise, whether or not it is bound.
What else you will see
Very little — DBSC is designed to be invisible when it is working.
The other place it surfaces is your Audit Trail, which records the lifecycle of each bound session — when a session was registered, when it was refreshed, and when it was revoked or terminated. An entry recording that a session was terminated by enforcement is worth a look: it means a request presented your session without the matching device proof.
You will also see a __Host-report_uri_dbsc cookie on your browser's cookie list for report-uri.com. That is the short-lived bound cookie described above; it holds no personal data and is listed in our Privacy Policy.
If something goes wrong
Because refresh is automatic and silent, a failure is silent too — the affected session simply ends and you are returned to the login page. Logging back in registers a fresh bound session.
If you find yourself repeatedly logged out on a device that supports DBSC, please get in touch and include the approximate times, so we can match them against the audit trail entries for your account.
Open source
The server-side implementation behind this feature is published as an open source PHP library, report-uri/dbsc-php, so anyone can implement DBSC on their own site.