Google recently released Device-Bound Session Credentials (DBSC) for Google Chrome and Google Workspace. It is a long-awaited new security enhancement to fight back against local cookie theft. But, yes, it can still be hacked and phished. Nothing alone in cybersecurity is a complete panacea.
The new standard says “Credentials,” but it is mostly referring to “cookies.” I suppose it could be applied to other types of login credentials like JWT tokens, so credential is probably a better description…but it mostly refers to browser cookies right now.
What Are Cookies?
Cookies are small text files sent to your browser after you have successfully logged in to an HTTP-/HTTPS-enabled site or service. No matter how you logged in, whether it was a login name and password, multifactor authentication, passkey, or biometrics, your browser will be sent a small text file (known as a cookie) that is then stored locally in a folder, usually under your browser directory or user profile.
For example, Google Chrome cookies on a Microsoft Windows computer will be stored at C:\Users\<UserProfileName>\AppData\Local\Google\Chrome\User Data\Default\Network. On Mac systems, they are stored under ~/Library/Safari/Website Data.
The cookie usually only contains a small amount of information, such as expiration date, time, and a randomly generated session key that the site or service uses to track your login identity while it is on the site or service. A cookie is an identifier. It essentially tells the site or service, here is who I am and I have successfully logged in.
A cookie might contain text that looks like this:
Document.cookie = “li_at=AQEDASYaneadRaidf45ww4adfasdfvmaaredAAGHadfaer42ff235; expires = 2026-08-11 07:10:11”
Cookies are also known as access control token cookies and session cookies. The latter name refers to the fact that a cookie is usually only good for one or more sessions. If you log out of a site or service, you may be required to re-authenticate, although often a cookie will allow a user (really their browser) to reconnect to a site or service for weeks to months without having to log in again. As long as the cookie is not expired, the user can go to the site and service and connect to it as the previously authenticated user. And on many sites and services, once you have a cookie and actively use it, you (really your browser) will be automatically issued new, unexpired cookies, so that you may never (or rarely) need to re-authenticate once you have logged in the first time.
Once your browser has it, you can usually move freely among the site or service, at least up to the extent of your permissions and privileges. The cookie is the way of an HTTP-enabled site or service tracking what you do as you move among the site or service.
The higher the security for the site or service, the more often you will be required to re-authenticate and get a new cookie sooner. But many sites and services essentially use cookies to keep the user logged in without having to re-authenticate, sometimes for years. Many times the only time a user will be required to re-authenticate to a particular site or service is when something major happens that wipes out their cookie, like a big operating system upgrade, new user profile, or crash.
Trouble With Cookies
Cookies are “bearer tokens”, meaning that whoever has and uses it will be treated as the original, legitimate logged-in user. Hackers and malware often steal user tokens and then use them on their computers. Password-stealing Trojans, such as LummaC2, if they gain administrative access to a computer, will try to steal its stored passwords and cookies. Unexpired cookies are often as good as login credentials.
Man-in-the-Middle (MitM) hacking sites (Microsoft calls them Adversary-in-the-Middle) can also steal issued cookies by social engineering the user into connecting to a MitM site first instead of the intended site or service the user thought they were going to. Once the attacker has successfully established a MitM site in between the user and the intended site or service, anything the client sends to the server and vice versa can be stolen. MitM sites often steal a user’s cookie as it is issued by the legitimate site or service or as the user passes it along to the site or service.
If I steal a cookie from you, I essentially become you when I visit that site or service. Password and cookie-stealing Trojans and MitM sites have stolen billions of cookies each year. It is a huge problem.
Here is a video demonstration of a MitM attack stealing a cookie involving LinkedIn and multifactor authentication: https://www.youtube.com/watch?v=xaOX8DS-Cto.
Cookie theft has been the bane of the cybersecurity industry for decades. Millions and millions of cookies are stolen each year, resulting in a lot of damage.
What are Device-Bound Session Credentials?
To partially fight cookie theft, Google created Device-Bound Session Credentials. Here are some related links for more information:
- https://www.w3.org/TR/dbsc/
- https://developer.chrome.com/docs/web-platform/device-bound-session-credentials
- https://workspaceupdates.googleblog.com/2026/05/prevent-account-takeovers-with-DBSC-now-generally-available-in-the-Chrome-browser-for-Windows.html
- https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/
- https://x.com/XavierRiveraX/status/2060343341334589710
- https://www.corbado.com/blog/device-bound-session-credentials-dbsc
Right now, DBSC only works with Google Chrome on Chrome OS and Microsoft Windows, but soon it will also work on MacOS and will likely be expanded to other OS’s and browsers.
How DBSC Works
First, a site or service must be coded to use DBSC. Unfortunately, making a site or service DBSC-enabled is not as easy as adding a new login method through a few lines of code. Participating sites and services will have to add the new login method AND add one or more dedicated registration and refresh endpoints to their backends. It is not particularly hard, and how to add DBSC to a site or service is well documented. Still, anything that adds a little complexity to anything tends to hamper widespread adoption.
Note: Ask FIDO about how hard it is to get the world to adopt better cybersecurity. FIDO has been trying to get FIDO credentials and passkeys added as a common login method for over 10 years and FIDO still does not work on 1% of websites. But I applaud both Google and FIDO for trying their best to give the world better cybersecurity. It is a chicken-and-egg problem.
Back to DBSC. When enabled and supported on both the client and the server, AFTER a user successfully logs in, the server will send back a “long-lived” cookie AND a “Secure-Session-Registration” label in the HTTP response header.
A DBSC-enabled browser will recognize the label and start the “registration” process if needed for a first-time DBSC registration to that site or service. The server’s Secure-Session-Registration response will include a URL path to the server’s registration endpoint.
A DBSC-enabled browser will generate a brand new asymmetric key pair (private and public key) tied to the user, their secure chip, and the involved site and service as identified by the URL. The browser will then connect to the server’s registration endpoint with the newly generated public key related to a private key stored on the client’s Trust Platform Module (TPM) chip or Apple’s Secure Enclave chip.
Note: I assume this will be expanded to Chromebooks/Android’s Titan M2 secure chip, but I have not seen any news on that yet.
The newly generated key pair tied to the user’s secure chip is one of the most important points…it is the “device-bound” portion of the process. The client public key sent to the registration server is tied to a private key stored on the secure chip. It is theoretically impossible (or at least non-trivial) for an attacker to access the private key stored on a TPM or other cryptographically secure chips.
You have to have a secure hardware chip, like the TPM or Secure Enclave, to participate in DBSC. TPM chips have been around on Windows computers since 2007 and are required for Windows 11. So, if you have Windows 11, you have a TPM chip. Apple has been using Secure Enclave chips since 2012. Google Chromebooks and Android Pixel 3 devices have been using T2 chips since 2018.
Because only the secure chip can generate the correct type of public key for the registration tied to a particular secure chip, someone outside of that machine cannot forge a new registration public key tied to the user and their device.
The server registration endpoint takes the client’s public key, validates it (using a process that involves the client’s secure chip’s use of its private key without revealing the private key) and stores it as related to that particular user and device. At this point, the DBSC session is “bound."
But this is not the cookie that is used for the current, live session. Once the DBSC session is bound, the participating site or service issues “short-lived” session cookies. They are only good for a short period of time (say five minutes). If an attacker is able to steal one, it is only good, at best, for a short period of time (a few minutes).
On legitimate clients, the short-lived session cookies are updated at a set number of minutes. Only clients and devices bound to the originally registered long-lived session can “refresh” their short-lived cookies. The user’s originally generated public key that was stored on the registration server is validated and a new short-lived cookie is issued. Only the same device that issued the long-lived public key can get updated short-lived keys. Getting new short-lived cookies (tied to the original long-lived cookie) is called “refreshing”. Clients connect to a “refreshing” endpoint to refresh their cookies. Thus, each participating DBSC site or service must have two new endpoints, a registration and refresh.
All of this (e.g., registration and refreshing) is invisible to the end user. Their browser does not show them any messages. All the DBSC negotiations, cookies, key sending, and key validation are done very quickly. It does slow down the login process, but not in a greatly noticeable way. Most users will not notice anything different.
DBSC will prevent traditional cookie stealing from being as effective and profitable as it is today. According to Google, it has already, just in limited beta, stopped millions of stolen cookie attacks. That is wonderful news.
Note: DBSC only works with HTTPS-enabled pages.
DBSC was created with privacy built-in as much as it can be. Participating sites and services only see the user’s site- or service-specific public key, tied to that one site or service. They do not see the user’s machine name or device ID (at least from using the DBSC process). DBSC is not even inherently tied to a user’s identity. It is tied to a device. The DBSC server is likely tying the user’s login name to a device, but that is on their backend and not an inherent part of the DBSC process. All DBSC cares about is device IDs, based on the submitted public key tied to a private key.
DBSC Is Still Phishable
As much as I love DBSC, it only prevents certain types of theft, mainly local cookie theft. This is not a surprise. Its creators understood this. There are still many ways to abuse a user’s session cookies. Here are some:
- If the hacker or the malware program is on the victim’s device, they can reuse and update cookies just as the user can do. If a hacker or malware is on your device, it is always game over (at least while the hacker or malware is on your device).
- Hackers and malware can create secondary, “hidden” sessions on a user’s device and use the DBSC cookies without the user knowing.
- A short-lived stolen cookie is good until it expires. Even if a short-lived stolen cookie is only valid for a few seconds, that is enough time for a hacker or automated malware to log in to the site as the user and manipulate the user’s profile in a way to take control of the account.
- If a hacker or malware program has stolen the user’s login credentials, it can register the user’s original session to its device. The DBSC server has no way of knowing that it is not the legitimate user registering another device.
- A hacker or their malware program can even present non-secure chip-generated public keys to a DBSC server and that server would not know that a secure chip was not involved. With this method, an attacker could make the device-bound cookies not bound to a particular device.
- Susceptible to cross-site scripting attacks, although a site or service can be configured to prevent them.
- Denial-of-service attacks are still possible.
Lastly, users routinely lose their cookies or need new cookies for legitimate reasons. It can be because they installed a major new OS or browser upgrade, started using a new browser, had their system crash, or started a new session from a different legitimate device (your cookies do not always travel from device to device). There are a lot of reasons why a legitimate user would need to generate new cookies. DBSC understands this. And because of this, DBSC had to make it easy for a user to generate a new DBSC-enabled long-lived cookie.
Attackers can take advantage of this. A local or MitM attacker can simply request a new login session to a legitimate site or service, even if the user was already previously logged in and has already generated the necessary DBSC cookies. The user will be asked to re-authenticate, which most users would just assume is necessary and normal, and the local or MitM attacker could manipulate the request so that the DBSC-binding is done to its machine versus the legitimate-originating user.
If DBSC ever goes widespread, I have to assume that local and MitM attackers will start to do this sort of manipulation and that most users will none-the-wiser. This is to say, DBSC is a good thing, but it will not stop hackers from abusing the cookie process. It will prevent millions and millions of currently configured attacks, but if DBSC became widely used, attackers would just change their defaults and start using methods that DBSC was not designed to stop.
With this said, DBSC does stop simple cookie theft and reuse on a new device and that will stop tons of existing attacks. For that reason alone, DBSC is great.
There are some potential plans to strengthen DBSC so that once registration is done, it is harder to force a new registration. But until then, expect hackers to start to use social engineering attacks that generate new DBSC cookies.
The biggest question is how many sites and services will adopt DBSC? Will most sites and services? My best guess is not, just like FIDO is facing. Google will certainly adopt it in as many places as it can. That is a big win, at least for Google-related sites and services. One of the biggest stolen cookie targets is Gmail. Gmail is already using DBSC. So, an attacker cannot use stolen cookies on Gmail.
We are still waiting to see if Microsoft Edge, Firefox, Opera, and other browsers start using DBSC. But the best guess is that 99% of sites and services will not adopt and use DBSC, and will not unless it becomes an official requirement. And even if DBSC was widespread, attackers and their malware programs would just pivot to social engineering scenarios where DBSC is just bypassed or manipulated.
Still, if you and your end users start using DBSC-enabled sites and services (e.g., Gmail), it cannot hurt to share education about DBSC. You probably do not want to go into the technical details as I did above. It is probably enough to educate end users to be aware if they suddenly have to log into a DBSC site or service more often than would normally be needed.
Unfortunately, I do not think most users (or possibly even myself) can be made aware enough to pay attention to one “unneeded” login. I mean, how many times are you asked to login again when you are not hacked? It happens all the time. Being asked to do a single “unneeded” login is probably not going to be noticed.
So, I love DBSC for what it does, but for a myriad of reasons, it is not likely to stop malicious cookie shenanigans. And I think many people reading about DBSC not understanding this might be tricked into thinking DBSC stops all malicious cookie use, and it does not.
It is like MFA. MFA is good. Use it when and where you can to protect valuable data and sites. But many people who are told to use MFA think they cannot be hacked when nothing could be further from the truth. Do not allow DBSC to be oversold to you or your users.
DBSC is a good thing. I love it. It is long overdue. Kudos to Google for doing it. But it is not likely to stop a lot of hacking in the long run. I hope I am wrong.
