Serious Discussion Google Locks Chrome Sessions to Devices to Stop Cookie Theft

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
969
4,663
2,168
Germany
Google has officially launched a major security upgrade to protect users from session hijacking. Starting with Chrome version 146 for Windows users, Device Bound Session Credentials (DBSC) is now publicly available.

This new feature aims to stop malware from stealing web cookies and using them to bypass passwords and multi-factor authentication. Support for macOS users will arrive in an upcoming Chrome release.

Session theft happens when a user accidentally downloads malware, such as the LummaC2 infostealer. Once on a device, this malware quietly copies existing session cookies from the browser’s local files and memory.

Attackers then send these stolen cookies to their own servers, allowing them to access user accounts without ever needing a password. Hackers frequently bundle and sell these active session tokens on dark web forums to other cybercriminals.
Read more here:


 
Last edited by a moderator:
Read more here:
Google is referring to a real browser security improvement, but the linked article should still be treated as a secondary source rather than the authority.

What DBSC does

Device Bound Session Credentials are designed to make stolen session cookies less useful by tying part of the session validation to the original device.

In practical terms, that means:

  • A stolen cookie alone may no longer be enough to reuse the session on another machine
  • This specifically helps against infostealers and session hijacking attacks
  • It is an additional protection layer, not a complete replacement for passwords, MFA, or good endpoint security

Important limitation

This does not mean session theft is solved.

If malware is actively running on the victim’s system, the attacker may still be able to abuse the session locally, inject into the browser, or steal other data. DBSC mainly raises the difficulty of replaying stolen session material from a different device.

Why it matters

Infostealers such as Lumma and similar families have made cookie theft extremely valuable to attackers because it can bypass normal login prompts.

A protection that binds session use to device-held credentials is a meaningful step forward because:

  • It reduces the resale value of stolen session data
  • It makes account takeover harder in many real-world cases
  • It gives websites a stronger way to verify that a session is still being used from the original endpoint

A note of caution about the article

I cannot verify the article’s exact rollout details from that quote alone, including the specific Chrome version timing, so it is best to confirm those details through Google or Chromium documentation before treating them as final.

Bottom line

The security concept is solid and useful: binding sessions to a device can significantly reduce classic cookie replay attacks. It is a strong improvement, but not a magic fix for systems already compromised by malware.

Sources
 
Please note that even though DBSC is enabled by default in Chrome, this does not mean you are as protected as I am, since I have enabled the three specific flags described in my security configuration.
This is because all news reports should clarify that protection only works if websites have implemented DBSC.

The first flag essentially forces more websites to use DBSC.
The second flag I use enforces protection on websites that use an external authentication system for example, when you access Firefox’s free VPN using your Google account.
Of course, this isn't actually the case I'm just using Firefox as an example to help explain the concept.(y)
The third flag forces DBSC protection to be enabled on Google websites, so even if you log in to YouTube, Gmail, etc.

Maximum security (available) = 3 DBSC flags enabled

;)
 
Last edited:
A test of the new feature against few infostealer samples would be appreciated, especially after the article you posted regarding its bypass.
In this case, testing infostealer samples would not be viable since it doesn't prevent cookie stealing; it makes the stolen cookie useless on a different device.
It seems that this "Device Bound Session Credentials" feature has to be adopted by websites to make it work. I don't know how many websites have adopted this. Google.com surely has, but I don't know about other sites.
Maybe @Jack can tell us if MalwareTips already has or will try to adopt DBSC for user sessions.
 
Then threat actors will find some way to bypass, just like "rat and cat" game of YT and adblockers.
If they can bypass this, they can bypass passkey/FIDO2 2FA stored by Windows Hello as well. The private keys protected by the TPM aren't supposed to be exportable. All secrets protected by the same public-key cryptography + TPM would fail.

I was looking at the Google blog's protocol on cookie refresh and it didn't make sense, so I checked elsewhere and I think the article's graphic designer and the editor made a mistake.

1775974869040.png

Here are the right versions.

Sources:
1775975009144.webp
1775975168760.png
 
DBSC è quasi certamente già disponibile sui siti web di proprietà di Google.
Tramite l'utilizzo di flag specifici, è possibile abilitare DBSC anche su siti web di terze parti che utilizzano l'accesso tramite Google (X.com..........).
È facile constatare che, senza dover fare nulla, si ottiene un ulteriore livello di protezione che migliora la sicurezza e la privacy complessive.
 
Last edited:
DBSC è quasi certamente già disponibile sui siti web di proprietà di Google.
Tramite l'utilizzo di flag specifici, è possibile abilitare DBSC anche su siti web di terze parti che utilizzano l'accesso tramite Google (X.com..........).
È facile constatare che, senza dover fare nulla, si ottiene un ulteriore livello di protezione che migliora la sicurezza e la privacy complessive.

DBSC is almost certainly already available on websites owned by Google.
By using specific flags, you can also enable DBSC on third-party websites that use Google Sign-In (X.com..........).
It’s easy to see that, without having to do anything, you gain an additional layer of protection that enhances overall security and privacy.

I had two browsers open when I ran the first DBSC test using Google and Gmail, and I repeated it with Firefox and at least 10 tabs open.
I definitely made a mistake in my writing.
Sorry.o_O
 
DBSC is almost certainly already available on websites owned by Google.
By using specific flags, you can also enable DBSC on third-party websites that use Google Sign-In (X.com..........).
It’s easy to see that, without having to do anything, you gain an additional layer of protection that enhances overall security and privacy.

I had two browsers open when I ran the first DBSC test using Google and Gmail, and I repeated it with Firefox and at least 10 tabs open.
I definitely made a mistake in my writing.
Sorry.o_O
I have translated the post using Brave translation.
 
As always, it will take long time before websites implement this technology. Maybe in 10 years we'll see much increased adoption like that was the case with HTTPS. For now and foreseeable future the best protection method is to avoid downloading suspicious files from the internet.
 
As always, it will take long time before websites implement this technology. Maybe in 10 years we'll see much increased adoption like that was the case with HTTPS. For now and foreseeable future the best protection method is to avoid downloading suspicious files from the internet.
My all time concern, "preventive" rather than "curative" cybersecurity.
 
  • Like
Reactions: Marko :)
As always, it will take long time before websites implement this technology. Maybe in 10 years we'll see much increased adoption like that was the case with HTTPS. For now and foreseeable future the best protection method is to avoid downloading suspicious files from the internet.
I feel this method of protection is more promising than Google's previous elevated-process protection (even from the get-go), and I hope that:
  • Other browsers, especially Firefox, will implement it.
  • Other high-value or frequently targeted websites will adopt it.
My most concerning account right now is Google anyway. This is supposedly an open standard through the W3C; maybe seeing results (already from Google) and some adoptions (less optimistic) will push Firefox to follow.