Cryptography & Security Newsletter

Google Debuts Device-Bound Session Credentials Against Session Hijacking

28 August 2025

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

HTTP cookies were never intended for session management, but that’s what we ended up with. Modern-day applications may have shifted to other methods, such as JSON Web Tokens (JWTs), but the traditional session management approach is based around the concept of a session identifier, which is a temporary authentication (bearer) token that gives access to the application session state. This is not insecure in itself, but it’s problematic when session identifiers are transported using cookies, which were never designed for security. These weaknesses gave rise to session hijacking attacks.

Over the years, many attempts have been made to make HTTP cookies secure, with features such as the Secure flag, then the HttpOnly flag, another feature called Name Prefixes, and then the Same-Site concept. And those are in addition to a series of changes to how browsers handle cookies. All of this helped, but it didn’t solve the problem.

My own research into this situation—too many years ago—led me to look into the possibility of binding HTTP sessions to TLS sessions. The idea was simple: You attach the observed TLS session identifier to the HTTP session on the first request, then you check that it remains the same on subsequent requests. The thinking was that the TLS session was going to stay the same for the original user, but be something else for the attackers. I was very pleased to discover that it worked in all browsers—except in Internet Explorer, which limited the duration of TLS sessions to only five minutes. And that was that.

The Rise of Cookie-Theft Malware

In the early days of session hijacking, the main attack vector was lack of encryption. Anyone with access to the local network traffic could observe session identifiers in plaintext—for example, by using Wireshark. In fact, there was once (in 2010) a famous Firefox extension called Firesheep that automated the entire attack and made it trivial for anyone to execute.

Eventually, HTTPS became ubiquitous, and cookies became sufficiently secure to make session hijacking a thing of the past. However, as our security started to improve, the criminal networks looked for other options. For many years, password compromise was the preferred exploitation option, but the rise of two-factor authentication made that venue less and less feasible. The attackers then pivoted to cookie-theft malware.

An infostealer, as this type of malware is also called, is conceptually simple: It tricks the victim into running a piece of software that looks around their hard disks for anything of value; in the past, this included passwords, and now it also includes session tokens. Passwords may be worthless to access accounts protected with two-factor authentication, but session tokens can be used immediately.

Enter Device-Bound Session Credentials

For more than a decade, plenty of people at Google tried to design a channel binding mechanism to improve HTTP session security in such a way that session hijacking would become impossible. You may have heard the same concept called channel ID or token binding. For one reason or another, they couldn’t get it to work—until, perhaps, now.

The first we heard about Device-Bound Session Credentials (DBSC) was in a blog post from April 2024, when Google announced that it was experimenting with something new. Fast-forward to last month, when Google announced a beta of the new protections in Google Workspace for users running Chrome on Windows. In the UI, there’s just a checkbox that you need to tick.

Underneath, DBSC is based on public-key cryptography. For every session, a pair of keys is created and stored securely on the device, in a way that makes them difficult to recover. On Windows, Chrome will use Trusted Platform Module (TPM), which is available in about 60 percent of installations. The session-specific private key can be used periodically to prove that the access is attempted from the same device. With this, session identifiers become useless on any other device.

Sounds great! Now we just have to wait to see if the other browser vendors like the idea. If they do and they adopt DBSC, then session hijacking will finally become a thing of the past. It’d be nice to know that some problems are never coming back. The DBSC standard lives as a W3C standard.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Selected Usenix Security ‘25 Papers

The 34th Usenix Security Symposium has been held in Seattle, and the materials are now available. There is a ton of information to process; the full proceedings are in a 1.2 GB PDF file. Here’s my list of interesting papers related to cryptography, without commentary and in the order I discovered them:

Short News

We have a great many news stories this month. Short news, long list. Happy reading!

Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.

Remote and trainer-led, with small classes and a choice of timezones.

Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More