Device Bound Session Credentials: Making Stolen Cookies Useless
Sponsored by: Report URI - Third-party JavaScript can change at any time. Know when it does.
A stolen session cookie can be vastly more powerful than a stolen password. The attacker doesn’t need to phish the user, bypass MFA, or defeat their passkey; they simply replay the cookie and step straight into a fully authenticated session. That’s why info-stealers love browser cookies: they turn the messy business of account compromise into a simple copy and paste operation. Device Bound Session Credentials, or DBSC, neutralise this attack by making the cookie useful on the single device where the user logged in, and nowhere else.
Authentication Is Getting Stronger, Sessions Are Still Weak<br>I tweeted about this anecdotally recently but I really do feel like this point stands, and it's something that really struck me at the time.
It’s kind of crazy that after all the progress we’ve made with passwords, 2FA, and now passkeys, the end result is still just… a cookie!
Attackers will follow the value and take the path of least resistance, and that means shifting to abusing the authenticated session instead.… https://t.co/gGBbv81N7r<br>— Scott Helme (@Scott_Helme) April 22, 2026
I've long pushed for things that help boost account security, all of the things mentioned in my tweet. We all know they're a good idea and it's most likely that if you're here reading this post on my blog, a security/technical blog, you probably have all of these bases covered.<br>Strong, unique passwords on your accounts, probably in a password manager.<br>2FA enabled, most likely TOTP.<br>Passkeys where supported, they're gaining momentum.
But what I said in that tweet is right, if not a little limited on character count. All of those steps are for the initial authentication. The first time you land on the site and want to log in, you have to prove who you are, you have to authenticate. You punch in your password, supply your TOTP code, and the website says "Hi Scott". They've successfully authenticated you. But now we have a problem, because HTTP is a stateless protocol. I don't want to have to provide my password and TOTP code on every single request to prove who I am, I want the website to remember who I am. I want to maintain state!<br>set-cookie: sess=wo358oh9f3wy8gh<br>This little cookie, issued to us after we successfully authenticated, is exactly how we do that. This is how the website remembers that I am Scott, and all I have to do is provide it with each request that I send.<br>cookie: sess=wo358oh9f3wy8gh<br>When the website receives a request with that cookie, it can look it up in the session store and say "Aha! This is Scott".<br>That's it, that's all we get. That little string of characters called a cookie. No matter how good your password is, how many 2FA mechanisms you have, and whether or not you're up to your eyeballs in passkeys, that cookie is now your proof of identity. This is also why they're so dangerous, because when an attacker steals it, they become you.
The Path of Least Resistance<br>As account security improves, traditional attacks are becoming more difficult for attackers. In distant times they might have had a field day with a good password dictionary, but now, on the modern Web, attackers have had to become more sophisticated. Yes, phishing is still the most likely attack to be effective against users right now, but if passkeys keep gaining momentum, attackers are going to lose that arrow from their quiver too. When that happens, they'll do what they always do and move to the next weakest link in the chain, and we're already seeing signs that this is happening with the rise of the InfoStealer threat.<br>MITRE tracks Steal Web Session Cookie as a real adversary technique because stolen session cookies can allow an attacker to access services as an already-authenticated user, without needing the user’s credentials.<br>Microsoft describes modern InfoStealers as malware that collects not just passwords, but also session cookies and authentication tokens, which makes them directly relevant to post-login session hijacking.<br>Google describes cookie theft as an attack where malware steals a user’s session cookie, allowing the attacker to impersonate the user and continue their authenticated session.
InfoStealers have changed the economics of account takeover. Attackers no longer need to defeat the login process if they can steal the session artefacts created after the login process has already taken place. That makes session cookies an obvious target: steal the cookie, replay the session, and bypass login security altogether.
Device Bound Session Credentials<br>To neutralise the off-device replay of a stolen cookie, to even know that a cookie has been stolen and is being abused by an attacker, the application only needs to answer a simple question.<br>Is this cookie being sent from the same device it was issued to?
That is the promise of Device Bound Session Credentials (spec). DBSC...