Chrome Binds Sessions to Devices
Google started rolling out Device Bound Session Credentials in Chrome 146 for Windows, which ties session cookies to device hardware to make stolen browser state less useful to attackers. The change uses TPM‑backed device identity to reduce replay attacks, which will alter assumptions about session continuity for web apps. That shift means authentication abstractions that treated cookies as portable may need revisiting as browsers enforce stronger defaults. (theverge.com)
A browser cookie is usually like a concert wristband: if someone steals it, they can walk in without knowing your password. Google is changing that in Chrome 146 on Windows by making some login sessions prove they still belong to the original device. (security.googleblog.com) That old model is called a bearer token, which means possession is enough. If malware copies the cookie file out of your browser today, an attacker can often replay it on another machine and stay logged in as you. (github.com) Google’s fix is called Device Bound Session Credentials, and it adds a hidden key pair to the session. Chrome creates the key on the device, keeps the private half locked down, and lets the website check that the browser still holds it before honoring the cookie. (developer.chrome.com) On Windows, Chrome stores that private key with the Trusted Platform Module, which is a security chip built to keep secrets from being copied out. Google said Chrome 146 is the first public Windows rollout, with macOS support coming in a later release. (developer.chrome.com) (security.googleblog.com) That changes the economics of infostealer malware. A stolen cookie database used to be a resale product; with device binding, the attacker may need to keep operating on the victim’s actual machine instead of reusing the session somewhere else. (blog.chromium.org) (thehackernews.com) Websites do not get this protection automatically just because Chrome updated. Google’s developer documentation says sites have to integrate the Device Bound Session Credentials flow so their servers can register the public key and verify proof that the browser still controls the private key. (developer.chrome.com) Google has been testing this since announcing it in April 2024 through Chrome origin trials, which are limited developer test periods for new web features. The company said the feature is now entering public availability for Windows users in Chrome 146 after those earlier tests. (blog.chromium.org) (security.googleblog.com) This also chips away at a quiet assumption inside many authentication systems: that a valid session can move freely between environments as long as the cookie comes along. If browsers start treating sessions as tied to hardware by default, developers who built around portable browser state will need to rethink account recovery, device migration, and some automation flows. (developer.chrome.com) (github.com) Google is pitching this as one layer, not a replacement for passkeys or two-factor authentication. Passkeys help at sign-in, while Device Bound Session Credentials protect the period after sign-in, when a long-lived cookie has traditionally been the easiest thing for malware to steal. (workspace.google.com) (security.googleblog.com) So the practical change is simple even if the plumbing is not: copying a browser session is starting to stop being enough. For years, “logged in” was a portable file; Chrome is pushing it toward something closer to a house key that only works in one lock. (theverge.com) (developer.chrome.com)
