# Device Bound Session Credentials in Chrome, explained > With Device Bound Session Credentials in Chrome, a site reissues its session cookie only to the device with the key. A copied cookie lasts until it expires. Source: https://mosaicbrowser.com/blog/device-bound-session-credentials ## Device-bound sessions and the end of copying a cookie With Device Bound Session Credentials in Chrome, a site reissues its session cookie only to the device with the key. A copied cookie lasts until it expires. ![A copied cookie lasts until its next refresh, beside a screenshot: importing a cookie jar into a Mosaic profile](https://mosaicbrowser.com/covers/device-bound-session-credentials.webp) Device Bound Session Credentials, DBSC for short, tie a site's sign-in session to one device. When you sign in, Chrome makes a key pair, keeps the private key in the machine's security hardware where it can, and the site then re-issues its short-lived session cookie only to a browser that can sign with that key. A cookie copied to another computer keeps working until it expires, which a site sets in minutes rather than months, and then it stops. That ends a long-standing assumption: that a session is its cookie, and whoever holds the cookie holds the session. For cookie theft, that is the point. For moving your own sessions between your own browsers, it changes what an import can do. ## How device bound session credentials work in Chrome The protocol is written up as a W3C specification, and its moving parts are a handful of HTTP headers. 1. When you sign in, the site's response carries a `Secure-Session-Registration` header naming a registration endpoint and the signing algorithms it accepts. 2. The browser generates a key pair for this session. Where the browser uses the machine's security hardware, a TPM on Windows or the Secure Enclave on a Mac, the private key is made inside it and cannot be read out. The browser sends the public key to the registration endpoint, signed with the private one. 3. The server answers with a session description: an id, a refresh URL, and which cookies the session covers. Those cookies are issued with short lifetimes. 4. When a covered cookie is about to expire, the browser holds back the requests that need it and calls the refresh URL with a `Sec-Secure-Session-Id` header. The server sends a `Secure-Session-Challenge`, the browser signs it with the session's key, returns the signature in `Secure-Session-Response`, and gets a fresh cookie. The key never leaves the device, and the server never asks for anything else. Each session has its own key, and the site receives only that key's public half, with no device identifier and no attestation of what hardware is behind it. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Local first](https://mosaicbrowser.com/features/local-first) ## What changes for a copied cookie Before bound sessions, a session cookie was a bearer token. Malware that read a browser's cookie store could send the jar elsewhere and sign in as you from another country, with no password and no second factor, for as long as the site honoured the cookie. That is the attack DBSC was built against. With a bound session, the same copy is still accepted, briefly. The cookie in the jar is valid until its short lifetime runs out. Then the site wants a signature, the copied jar has no key to make one, and the session ends there. The stolen cookie has become a few minutes of access instead of weeks. What DBSC does not cover is stated plainly in its own specification. Malware running on your own machine can use your browser's session from there, because the key is right beside it. And an attacker who controls the browser at the moment of sign-in can register the session against a key of their choosing. It is a defence against a cookie leaving the device, nothing more. ## What cookie import still does Mosaic profiles each have their own cookie jar, encrypted on disk. You can import cookies into a profile as a JSON array, a `{cookies: [...]}` object, a Netscape `cookies.txt` file or a header line, and export them again, and an import reaches a running browser without a restart. That is how people bring their own sessions in from another browser or from one of the five anti-detect products Mosaic imports from. For a site that does not bind its sessions, nothing has changed. The imported cookie carries the session, and the profile is signed in. For a site that does, an import moves the cookie value and nothing else. The key that would refresh it is in the security hardware of the computer it came from, or tied to the browser it was registered in, and no file format carries it. So the imported session lasts until its bound cookie next needs refreshing, and then the site asks you to sign in. We have not measured how our own engine, Tesseract Chrome, behaves when a site offers a bound session, so we make no claim either way about registration inside a Mosaic profile. What holds regardless is the direction of travel: a cookie copied out of one browser is a weaker thing than it was. ## The durable way to bring a session into a profile Sign in inside the profile. The session then starts in that profile's own browser, with that profile's cookies, from that profile's exit, and whatever binding the site applies is to that browser rather than to one you are leaving behind. It also reads better to the site. A new device appearing with a session that has never been seen to sign in is exactly what risk checks look for; we explained Google's version of that in [why Google says "verify it's you" on a new device](https://mosaicbrowser.com/blog/google-verify-its-you). A fresh sign-in, with the account's own second factor, is the ordinary path every real new device takes. Cookie import keeps its place for the sites that do not bind, for moving a library between your own browsers, and for restoring a profile's jar. Once a session has started inside a profile, keeping that jar intact is the part that matters: it is why [Seller Central stops logging you out](https://mosaicbrowser.com/blog/seller-central-keeps-logging-out) once each store has its own jar. ## Where this sits with third-party cookies Bound sessions are about first-party sign-in cookies, the ones a site sets for itself to remember who you are. They have nothing to do with the long argument over third-party cookies (the state of that argument is in [Chrome kept third-party cookies](https://mosaicbrowser.com/blog/chrome-keeps-third-party-cookies)). A profile still needs its own jar for both reasons: so one account's sign-in never lands in another's, and so a tracker's cookie set in one profile is never read in the next. Mosaic keeps those jars on your computer, with no cloud copy of your profiles ([local first](https://mosaicbrowser.com/features/local-first)). ## Questions ### What are Device Bound Session Credentials? DBSC is a protocol in which the browser makes a key pair when you sign in, keeps the private key in the computer's security hardware where it can, and proves it holds that key each time the site re-issues its short-lived session cookie. ### Does DBSC stop cookie theft? It stops a stolen cookie from being useful for long. The copy works until the short-lived cookie expires, and then the refresh needs a signature from the key on the original device, which the thief does not have. It does not help against malware still running on that device. ### Is DBSC a fingerprint? The protocol gives each session its own key and sends the site only that session's public key, with no device identifier. A site can tell the same session is still on the same device, which it could already tell from its own cookie. ### Can I still import cookies into a browser profile? Yes. Importing writes the cookie values into the profile's jar. For a site that binds its sessions, those values last until the bound cookie next needs refreshing, and then you sign in again inside the profile. ## Related [Chrome kept third-party cookies. What that means for cookie jars](https://mosaicbrowser.com/blog/chrome-keeps-third-party-cookies): Chrome is not removing third-party cookies: Google dropped the phase-out and then the prompt. A jar per account matters as much as it did before. [Why Google says 'verify it's you' on a new device](https://mosaicbrowser.com/blog/google-verify-its-you): Google asks you to verify it's you when a sign-in comes without the cookie its last sign-in left, or from an address in a place you have not been. [Why Seller Central keeps logging you out](https://mosaicbrowser.com/blog/seller-central-keeps-logging-out): Seller Central signs you out when its cookies go: a cleaned browser, a second store in the same window, a private tab. Keep one store per cookie jar. [Local first: your profiles stay on your computer](https://mosaicbrowser.com/features/local-first): Mosaic has no cloud copy of your profiles. Profiles, cookies and proxies stay on your computer, encrypted on disk, with app lock, daily backups and a trash. [App-Bound Encryption, and why tools stopped reading Chrome's cookies](https://mosaicbrowser.com/blog/chrome-app-bound-encryption): App-Bound Encryption ties Chrome's cookie key on Windows to Chrome itself, so tools reading the Cookies file broke. Export from inside the browser. [Chromium's mock keychain, and why we encrypt the store](https://mosaicbrowser.com/blog/mock-keychain-cookies): Chromium's --use-mock-keychain keeps cookie encryption on but uses a password from its own source. We read a live session cookie off disk, then sealed it.   ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.