Chrome 146 Ties Your Login to Your Hardware—Stolen Cookies Are Now Useless

The Cookie Theft Problem

Session cookies are the keys to your online accounts. When you log in to Gmail, your bank, or any web service, the server issues a cookie that proves your identity for the rest of the session. Steal that cookie and you become that person, no password or two factor code required.

Infostealer malware has turned cookie theft into an industrial operation. Families like LummaC2, Atomic, and Vidar specialize in extracting browser credentials from infected machines. Once malware has access to your computer, it can read local files and memory where browsers store authentication cookies. No amount of software protection on the operating system can reliably prevent this.

The scale is staggering. Security researchers estimate that at least 17 billion session cookies were compromised in 2024 alone. Each stolen cookie represents a bypassed login, and the victim often has no idea it happened.

What Chrome 146 Changes

Chrome 146 introduces Device Bound Session Credentials (DBSC), a feature that cryptographically binds your session to your computer's hardware security chip. On Windows, it uses the Trusted Platform Module (TPM). On macOS, it will use the Secure Enclave.

Here is how it works:

• When you start a session on a website that supports DBSC, Chrome generates a unique public and private key pair inside the hardware security chip
• The private key never leaves the chip. It cannot be exported, copied, or read by any software on the machine
• The server issues short lived session cookies that expire quickly
• To get new cookies, Chrome must prove it holds the private key by completing a cryptographic challenge
• If the cookie is stolen and used on a different machine, the proof fails and the session is rejected

The result: even if malware exfiltrates every cookie on your machine, those cookies become useless the moment they leave your computer. The attacker's machine cannot complete the cryptographic proof because it does not have the hardware bound key.

Privacy by Design

Google designed DBSC to solve one problem without creating another. Each session uses a distinct cryptographic key, so websites cannot correlate your activity across sessions or across different sites. The protocol only exchanges the minimum per session public key data needed for verification. No device identifiers are shared.

This matters because previous hardware binding approaches risked creating a new tracking vector. If every site received the same device ID, it would function as a super cookie. DBSC avoids this by generating fresh, isolated keys for every session on every site.

What Is Available Now

DBSC is live in Chrome 146 on Windows. If your computer has a TPM chip, which nearly all modern Windows machines do, the protection is active automatically for websites that support it. Google partnered with Microsoft during development and published DBSC as an open web standard through the W3C.

MacOS support is planned for a future Chrome release but has no announced date. Google conducted a year of testing with partners including Okta and observed decreased session theft incidents during trials.

For website operators, adoption requires adding dedicated registration and refresh endpoints to their backends. Existing frontend code does not need changes. Google provides implementation guidance through its developer documentation.

What This Does Not Fix

DBSC protects against remote cookie theft: an attacker who steals your cookies and tries to use them elsewhere. It does not protect against malware that operates directly on your machine in real time. If an infostealer is actively running on your computer, it can use the session while you are logged in because the hardware key is still present.

It also requires website adoption. Until major services implement the DBSC endpoints, the protection only works on sites that have opted in. Google's own services will likely be early adopters, but the broader web will take time to catch up.

For complete browser security, DBSC works best alongside other protections: keeping your browser updated, using trusted extensions rather than malicious ones, and avoiding the ClickFix social engineering attacks that install infostealers in the first place.

The Bottom Line

For years, the security community accepted that cookie theft was unsolvable at the browser level. DBSC proves otherwise. By anchoring sessions to tamper resistant hardware, Chrome 146 makes the most common session hijacking technique functionally obsolete for every site that implements it.

The protection is automatic for Chrome users on Windows. There is nothing to install, configure, or turn on. If you are still running an older Chrome version, update now. The feature only works in Chrome 146 and later.