Home

Published

- 8 min read

Passkeys Were the Start: Google's DBSC Will Make Cookie Theft Obsolete

img of Passkeys Were the Start: Google's DBSC Will Make Cookie Theft Obsolete

For the past two years, Passkeys have been praised as the future of online security. Security experts have supported them as a powerful way to stop phishing and replace passwords. And for logging in, Passkeys have worked very well.

But what happens right after you log in?

At that point, a new piece of data is created: the session cookie. This small file in your browser proves you’re logged in. For attackers, it’s now the main target. If they can’t steal your password, they’ll steal your session cookie instead. This leftover risk from the password era is still causing major security breaches today.

Until now. Google is rolling out a groundbreaking new browser feature called Device-Bound Session Credentials (DBSC). If Passkeys were the lock on the front door, DBSC is the cryptographic security system that arms itself the moment you step inside. This isn’t just an incremental improvement; it’s the beginning of the end for the entire class of attacks known as session hijacking.

Let’s be clear: session hijacking via cookie theft is one of the most effective attack vectors used today. It’s the silent threat that bypasses even the most robust Multi-Factor Authentication (MFA).

The attack is brutally effective:

  1. A user’s machine is infected with info-stealing malware (like Redline, Vidar, or Raccoon Stealer).
  2. The malware exfiltrates the browser’s cookie database.
  3. The attacker takes the session cookie for a critical service (like a corporate SaaS app, cloud console, or financial platform).
  4. The attacker injects this cookie into their own browser.
  5. Game over. The server sees a valid session token and grants the attacker full access to the user’s authenticated session. No password, no MFA prompt, just seamless, unauthorized access.

This is the critical gap that Passkeys, for all their brilliance, were not designed to solve. They secure the login, but they don’t secure the session that follows. DBSC is designed to plug that gap—permanently.

Enter DBSC: The “Passkey for Your Session”

Device-Bound Session Credentials (DBSC) is a new browser-based technology, currently in open beta via an origin trial in Google Chrome, that aims to make stolen session cookies completely useless.

The concept is both elegant and powerful: it cryptographically chains your session cookie to the physical device it was issued to.

Here’s a simplified breakdown of how it works, based on the technical details from the Chrome Developer team:

  • The Secure Handshake: A user logs into a website that supports DBSC (ideally using a phish-resistant Passkey).
  • Key Generation: The server, upon successful authentication, instructs the browser to generate a new, session-specific public/private key pair.
  • The Private Key Stays Put: The crucial part of this process is that the private key is generated and stored in a secure hardware element on the device, such as a Trusted Platform Module (TPM). It is designed to be non-exportable. It never leaves the user’s machine.
  • Binding the Session: The browser sends the newly generated public key to the server, which stores it and associates it with the user’s session.
  • Continuous, Transparent Verification: For every subsequent request to the server during that session, the browser automatically and transparently uses the device-bound private key to sign the request.
  • The Server Validates: The server receives the request and uses the public key it has on file for that session to verify the signature. If the signature is valid, the request is processed. If not, it’s rejected.

The “Aha!” Moment: Why Stolen Cookies Become Worthless Junk

Now, let’s replay our session hijacking scenario with DBSC in place:

  1. A user’s machine is infected with info-stealing malware.
  2. The malware exfiltrates the browser’s entire cookie database.
  3. The attacker extracts the session cookie for a DBSC-protected service.
  4. The attacker injects this cookie into their own browser and attempts to access the service.
  5. The server receives the request with the valid cookie but sees that it lacks a valid cryptographic signature.
  6. The server rejects the request. Access denied.

The stolen cookie is now just a useless piece of text. Without the original device’s private key to sign requests, the attacker cannot prove that their session is legitimate. DBSC effectively turns a session cookie from something you have into something you are (cryptographically speaking).

A CISO’s Action Plan: Navigating the DBSC Rollout

DBSC is a monumental step forward, but it’s not magic. It requires proactive engagement from security and development teams to realize its full potential.

1. For Security & Operations Teams: Prepare for the Future

  • Understand the Technology: DBSC is the next logical evolution in identity and access security. Educate your team on how it works and the problem it solves. This isn’t just another browser feature; it’s a fundamental shift in how session integrity will be maintained.
  • Champion Adoption: Start the conversation with your business and application owners. Frame DBSC as a critical defense-in-depth measure that complements your investment in MFA and Passkeys.
  • Review Browser Policies: Ensure your organization’s browser management policies allow for the timely rollout of new security features like DBSC as they move from origin trial to general availability.

2. For Development & Application Teams: Start Experimenting Now

This is the most critical piece of the puzzle. DBSC is an opt-in technology that requires server-side implementation. Your web applications must be updated to support it.

  • Join the Origin Trial: Google Chrome has made DBSC available as an origin trial. This allows your developers to start experimenting with the API on your web applications today. They can build and test the server-side logic required to create and validate device-bound sessions.
  • Prioritize Critical Applications: Identify the applications where a session hijacking would be most damaging—your cloud administration consoles, financial systems, core SaaS applications, and customer-facing portals. These should be the first candidates for DBSC implementation.
  • Plan Your Roadmap: DBSC, or a standardized version of it, will likely become a core web security standard. By adopting it early, you are not just mitigating a critical risk; you are gaining a competitive advantage by offering your users a verifiably more secure experience.

Conclusion: The Final Nail in the Coffin for Session Hijacking

For years, security has been a game of raising the cost for attackers. Passkeys raised the cost of initial authentication to a near-insurmountable level. Now, DBSC is set to do the same for the post-authentication world.

By binding a user’s session to their physical device with strong cryptography, we are finally closing the glaring loophole that has allowed session hijacking to thrive. The journey to a truly passwordless and secure future requires us to protect not just the login, but the entire user journey. Passkeys were the brilliant first move. DBSC is the decisive and necessary follow-up that promises to make one of the most pervasive and damaging attack vectors a relic of the past.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Device-Bound Session Credentials (DBSC) FAQ

  • What is DBSC? DBSC (Device-Bound Session Credentials) is a new browser technology, pioneered by Google, that cryptographically binds a user’s session cookie to their physical device. It uses a hardware-stored private key to sign requests, making stolen session cookies useless to an attacker.
  • Does DBSC replace Passkeys or MFA? No. DBSC is a defense-in-depth measure that complements Passkeys and MFA. Passkeys secure the initial authentication (the login), while DBSC is designed to protect the session after the user has logged in, preventing session hijacking.
  • How does DBSC stop cookie theft attacks? An attacker who steals a DBSC-protected cookie will not have the corresponding private key, which is securely stored on the victim’s device. Without this key, the attacker cannot cryptographically sign their requests to the server, and the server will reject their attempts to use the stolen session cookie.
  • When will DBSC be available? DBSC is currently available for developers to test and implement via an origin trial in Google Chrome. As with any new web standard, it will take time for websites to adopt it and for other browser vendors to implement it.
  • What do I need to do to use DBSC? As a user, you will eventually benefit from DBSC automatically as websites you use adopt it. As an organization, your web development teams need to actively implement server-side support for the DBSC protocol. They can start experimenting with this now through the Chrome Origin Trial.

Relevant Resource List