Cookies secured with DBSC: What is Google's Device Bound Session Credentials and How Does it Work?

Posted by

  

In the cybersecurity landscape, there is a silent threat that has brought millions of users and companies to their knees in recent years: session hijacking (or cookie theft). Specialized malware, called infostealers, can penetrate computers, copy session cookies from browsers, and send them to remote attackers. By cloning these cookies on their own PCs, attackers can access the victim's bank accounts, emails, or corporate dashboards, completely bypassing passwords and even Multi-Factor Authentication (MFA).

To put an end to this structural vulnerability of the web, Google has introduced a revolutionary technology: Device Bound Session Credentials (DBSC). Let's see in detail what it is, how it works from a logical and technical standpoint, and when you will be able to use it.

🔗 Do you like Techelopment? Take a look at the website for all the details!

1. What is DBSC?

DBSC is a new security protocol (developed within the W3C) whose goal is to inextricably bind a web session to the physical device on which it was created.

Instead of relying on classic cookies that behave like "bearer tokens" (whoever possesses them can use them), DBSC transforms the cookie into a useless key if moved outside the legitimate computer. If a malware copies a session cookie protected by DBSC and sends it to a hacker on the other side of the world, the hacker still won't be able to access the account.

The problem DBSC solves: The ineffectiveness of MFA against Infostealers

Until now, the best defense to protect an account has been Multi-Factor Authentication (MFA or 2FA). However, MFA steps in exclusively during the login phase. Once the user has successfully entered their password and OTP code, the web server generates a session cookie that is saved in the browser. From that moment on, that cookie represents the definitive "access pass": for the entire duration of the session, the user will no longer need to re-enter their credentials.

This is where infostealer malware (such as RedLine or Lumma) comes into play. These malicious programs don't need to steal your password or intercept your OTP code. They simply copy already active session cookies directly from the browser files saved on the hard drive.

Once the attacker obtains these cookies, they import them into their own browser and "clone" the victim's identity. To the web server, the attacker is the legitimate user, as they present a pass already authorized by MFA. DBSC solves exactly this problem at its root: it makes cookies completely unusable if they are extracted from the original computer's hardware, neutralizing the entire business model of infostealers.

You can learn more about how session hijacking works in this video.


2. How DBSC works at a logical level (the passport metaphor)

To understand the logic of DBSC, let's imagine the difference between a movie ticket and a passport:

  • The old system (Traditional Cookie): It works like a movie ticket. If you buy it, put it in your pocket, and someone steals it, the thief can show up at the cinema entrance and go in instead of you. The ticket collector only checks if the ticket is valid, not who owns it.
  • The new system (DBSC): It works like a biometric passport combined with a continuous customs check. When you log into a site, the browser doesn't just receive a "ticket" (the cookie), but generates a unique cryptographic link with your computer's hardware. At regular intervals, the site asks the browser: "Are you still on the same computer as before? Prove it". Only your PC possesses the hardware capable of responding correctly. The thief with the stolen cookie will fail the check.

3. How DBSC works at a technical and computing level

At the software and hardware infrastructure level, DBSC shifts security from the application layer (the browser alone) to the hardware layer (the computer's chip).

The process is divided into three macro-phases:

A. Registration (Login Phase)

  1. The user logs in by entering their password and MFA on a compatible website.
  2. The site's server responds by sending a specific HTTP header (Secure-Session-Registration).
  3. Upon receiving the header, Google Chrome commands the computer's security chip (e.g., the TPM on Windows) to generate a cryptographic key pair (Public/Private) specific to that site.
  4. The browser sends the public key to the site's server and keeps the private key locked inside the hardware chip. The private key cannot be exported or read by any malware.

B. Maintenance (Short-lived Cookies)

To avoid overloading the hardware chip with every single click on the page, the site still issues traditional session cookies, but with one fundamental difference: they have a very short duration.

C. The Challenge (Refresh)

When the short-lived cookie is about to expire, DBSC comes into play:

  1. Chrome contacts a refresh endpoint on the site's server.
  2. The server sends a "challenge" (a unique code called a nonce).
  3. Chrome digitally signs this challenge using the private key stored in the PC's hardware chip.
  4. The server receives the signature, verifies it with the public key stored at login, and, if valid, issues a new short-lived cookie.
Malware blocking: If malware installed on the PC copies the short-lived cookie and sends it to the attacker, the attacker will only be able to use it for a few minutes. As soon as the site asks to sign the "challenge" to renew the cookie, the attacker will fail because they do not possess the victim's hardware chip containing the private key.


4. Requirements and compatibility: which versions support it?

The release of DBSC is happening gradually but decisively, starting from corporate ecosystems and then expanding to all global users.

Component Minimum Requirement / Support Status Technical Notes
Google Chrome (Windows) Available (General Availability) starting from Chrome 145 / 146 Active by default for all users (including personal Google and Workspace accounts).
Google Chrome (macOS) Coming soon Support announced and currently being implemented.
PC Operating Systems Windows 10 / 11 with an active TPM 2.0 chip. DBSC requires the hardware Trusted Platform Module to secure the keys.
Mac Operating Systems macOS systems equipped with Apple Silicon or Intel chips with Secure Enclave. It will leverage Apple's native security architecture.
Other Browsers Under evaluation / In development Since it is a proposed open standard (W3C), Microsoft Edge, Mozilla Firefox, and Safari are also evaluating implementation in their respective engines.


5. What does the user need to do?

Absolutely nothing. If you use a recent version of Windows 11 or Windows 10 with TPM active and keep Google Chrome updated, the technology works in the background for you. Major service providers (like Google Workspace) have already begun protecting their users' sessions completely transparently, ensuring an incredibly safer browsing experience without sacrificing daily convenience.


References



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment