Google Proposed Device Bound Session Credentials To Prevent Session Theft – Will This Solve The Problem?
Google just rolled out something called Device Bound Session Credentials — DBSC for those who enjoy acronyms. But like most things that arrive wrapped in a press release, it’s worth taking a closer look before you decide whether to applaud or raise an eyebrow.
The basic problem DBSC is solving is one that’s been quietly embarrassing the security industry for years. When you log into your bank, your email, your everything, the browser stores a session cookie. That cookie is essentially a golden ticket. Steal it, and you don’t need a password or even a second factor, the website just waves you through because it thinks you’re already authenticated. And depending on your system setup, these cookies may be valid for up to 30 days or longer. Malware operators have gotten very good at extracting these cookies after they’ve socially engineered the user to provide access to the malware. DBSC puts a meaningful dent in that by binding the session to the cryptographic hardware inside your device. The private key never leaves your machine, so the stolen cookie is worthless somewhere else. That’s genuinely useful.
Proxy Exfiltration & The Anti Competitive Cookie Conversation
Here’s where I have to fact-check our own CISO, Gary Blosser, who had a lot to say about this.
His first point was that DBSC could quietly neuter every competing ad platform since cross-site tracking depends on browser-level data. That framing actually conflates two separate Google initiatives. DBSC is about session authentication cookies, not third-party tracking cookies. The anti-competitive cookie conversation is a real one. The UK’s Competition and Markets Authority has been watching Google’s Privacy Sandbox initiative closely for exactly those reasons. DBSC itself is being developed as an open web standard, and Microsoft Edge and Okta are already planning to adopt it. So the competitive concern is legitimate, just aimed slightly at the wrong target.
His second point was more technically precise: locking the cookie to the device doesn’t help much if the attacker’s malware is already sitting on that device. At that point, the attacker doesn’t need to export the cookie. They just use your infected machine as a live proxy, making authenticated requests through your own browser. Google’s own documentation actually acknowledges this, noting that malware with access during session registration could replicate the attack, though they describe it as “significantly more complex and detectable.” Gary called it proxy exfiltration, and that’s a fair characterization. It’s still an improvement, but it’s not a solved problem.
His last point and the one I find most interesting is about why session theft can never be fully eliminated. Before smartphones and cloud load balancing, you could simply invalidate a session any time the IP address changed. That worked beautifully. The problem is that your phone changes IP addresses every time it switches cell towers, and your corporate app traffic bounces through load balancers with different source addresses constantly. Forcing re-authentication every time that happens would make your users miserable, and so that simple, elegant fix was quietly retired when the infrastructure made it impractical. That’s not a Google problem, that’s just a structural constraint baked into how modern networks work.
Where does that leave DBSC?
It’s a real improvement against cookie theft at scale, particularly for organizations running managed devices where you can guarantee TPM hardware (Trusted Platform Module – an independent chipstack on phones and computers that handles facial and fingerpring recognition) is present. It raises the cost of the attack without eliminating it, and it works best as one layer in a stack rather than a standalone answer. The advertising angle deserves its own conversation, but it’s not the right lens for evaluating whether DBSC makes your users more secure.
What’s Next?
The question we want more data on here at TorchLight is… does raising the attack complexity on session theft solve the problem, or does incremental security progress just give organizations false confidence that the problem is handled?
In the meantime, Identity Theft Detection and Response Monitoring protection is the most confident way to prevent the access/exfiltration/ransom of critical business data. You can learn more about this service here.