Chrome adopts what may be the best protection yet against account takeovers - Ars Technica

Skip to content

AI

Biz & IT

Cars

Culture

Gaming

Health

Policy

Science

Security

Space

Tech

Forum

Subscribe

Story text

Size

Small<br>Standard<br>Large

Width

Standard<br>Wide

Links

Standard<br>Orange

* Subscribers only

Learn more

Pin to story

Theme

Search

Sign In

Sign in dialog...

Text<br>settings

Story text

Size

Small<br>Standard<br>Large

Width

Standard<br>Wide

Links

Standard<br>Orange

* Subscribers only

Learn more

Minimize to nav

Google’s Chrome browser has added a new feature that could go a long way in preventing a form of account takeover that’s grown increasingly common as users adopt two-factor authentication, passkeys, and similar protections.

The new Chrome protection is known as device-bound session credentials (DBSCs). The measure stores a unique encryption key in a silicon-resident fortress that’s built into the device running the browser. On Windows machines, this fortress is called a TPM, short for Trusted Platform Module. On macOS and iOS, it’s known as a secure enclave. Other platforms have differing names. Recently released versions of Chrome for Windows and macOS generate a key that’s stored in this fortress.

An antidote to session cookie theft

DBSCs protect against the theft of session cookies, the unique strings of characters that websites store on browsers. Session cookies greatly speed up browsing on sensitive sites that require user authentication. Instead of requiring the exchange of credentials each time a user opens a new site page, the server sets a session cookie that effectively proves the user has already successfully logged in.

The threat of session cookie theft has grown as 2FA, passkeys and similar protections have become more common. These newer protections require additional factors beyond a shared secret before a user gets access to a restricted site. Once possession of a mere password is no longer sufficient, phishing and other more traditional forms of account takeovers are no longer effective.

To compensate, attackers have increasingly relied on infostealer malware and adversary-in-the–middle attacks. Both forms of attack work by stealing session cookies. Attackers then paste the cookies into their own browser and gain the same access the rightful owner has (at least temporarily).

DBSCs are an antidote to session cookie theft. Once a website sets a session cookie, the visiting browser must send a form of the cookie that’s signed with the key stored in the silicon. Properties in the TPM or secure enclave isolate the key in a way that prevents it from being extracted. Apple explains the process here.

“The attacker can’t steal the private key from the device because the TPM / Secure Enclave will not release it. That is the core protection here,” Scott Helme, a researcher and founder of Report URI who blogged about the new protections on Tuesday, told Ars. “The attacker can steal the cookie, but they can’t answer a DBSC challenge by signing it with the private key, which is still safe on your device.”

For the moment, DBSCs are supported only in Chrome version 147 for Windows and 150 for macOS. Even then, DBSCs are turned on only for a limited set of users. Presumably, Google is testing the feature before making it generally available. Chrome users on Windows and macOS can check whether it’s running in their browser by opening developer tools, clicking on the application tab across the top, and scrolling down. When a user is logged into a site that supports DBSCs, “device bound sessions” will appear if the protection is turned on.

It’s unclear when, or if, other Chromium-based browsers will implement DBSCs, but it’s likely they will be coming.

DBSCs are the latest form of authentication that eliminates the reliance on a shared secret, which, as the world has known for years, is painfully easy for attackers to steal. Under this new model, web servers store the visitor’s public key. The servers then send an authentication challenge incorporating the session cookie. Unless the resulting answer, known as an authentication assertion, is signed by the private key stored safely in the TPM or secure enclave, the assertion is rejected. Passkeys—which you can read about in this post published earlier on Tuesday—work the same way.

Dan Goodin

Senior Security Editor

Dan Goodin

Senior Security Editor

Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.

29 Comments

Staff Picks

For anyone curious this is being worked on as a W3C standard and the work for it has been going on for months. https://w3c.github.io/webappsec-dbsc/

Happy to see progress in...