Fighting cookie theft using device bound sessions(blog.chromium.org)
blog.chromium.org
Fighting cookie theft using device bound sessions
https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html
11 comments
> At a high level, the DBSC API lets a server start a new session with a specific browser on a device. When the browser starts a new session, it creates a new public/private key pair locally on the device, and uses the operating system to safely store the private key in a way that makes it hard to export. Chrome will use facilities such as Trusted Platform Modules (TPMs) for key protection, which are becoming more commonplace and are required for Windows 11, and we are looking at supporting software-isolated solutions as well.
Seems like a cat-and-mouse game never ends, and now they want to include hardware mingling with cookies - go adtech, go!
If your user env is compromised its too late; just a matter of time before that vector gets exploited.
I dont want the same convince as other people choose to have; just force log me off of sites after a time limit, stop tracking me and give me my internet without javascript back (imagine going back to 2000 and suggesting to stop using Flash, lol)
Seems like a cat-and-mouse game never ends, and now they want to include hardware mingling with cookies - go adtech, go!
If your user env is compromised its too late; just a matter of time before that vector gets exploited.
I dont want the same convince as other people choose to have; just force log me off of sites after a time limit, stop tracking me and give me my internet without javascript back (imagine going back to 2000 and suggesting to stop using Flash, lol)
How does DBSC improve adtech at all?
The proposed design makes no mention of using TPM/device attestation and explicitly calls out that it is bound to the same restrictions that Chrome's removal of third-party cookies is introducing.
If a site (Google or other) cannot get an attestation with the key and keys are unique per eTLD then there's no new tracking vector introduced. A site can't get anything more than they can with a standard, first-party session cookie.
> just force log me off of sites after a time limit
Since this opinion is seriously in the minority as the overwhelming majority of people do not like the friction of having to log back into services, that's never going to happen for any sizable fraction of websites [†].
Thus, for everyone's security it would be better if sites adopt DBSC to prevent session-theft/cookie-theft without introducing the nuisance of constantly logging in.
Not to mention, every log-in with a password is opportunity for phishing/key-logging. If people had to log in 10-100x more frequently, that would only increase another form of malware. Only FIDO/Passkeys offer the ability to make frequent log-ins phishing resistant.
[†] - banks being a big exception since, prior to DBSC, there was no good way to prevent session-theft/cookie-theft outside of making sessions/cookies very short-lived. And they need to be worried about session-theft/cookie-theft because... money.
The proposed design makes no mention of using TPM/device attestation and explicitly calls out that it is bound to the same restrictions that Chrome's removal of third-party cookies is introducing.
If a site (Google or other) cannot get an attestation with the key and keys are unique per eTLD then there's no new tracking vector introduced. A site can't get anything more than they can with a standard, first-party session cookie.
> just force log me off of sites after a time limit
Since this opinion is seriously in the minority as the overwhelming majority of people do not like the friction of having to log back into services, that's never going to happen for any sizable fraction of websites [†].
Thus, for everyone's security it would be better if sites adopt DBSC to prevent session-theft/cookie-theft without introducing the nuisance of constantly logging in.
Not to mention, every log-in with a password is opportunity for phishing/key-logging. If people had to log in 10-100x more frequently, that would only increase another form of malware. Only FIDO/Passkeys offer the ability to make frequent log-ins phishing resistant.
[†] - banks being a big exception since, prior to DBSC, there was no good way to prevent session-theft/cookie-theft outside of making sessions/cookies very short-lived. And they need to be worried about session-theft/cookie-theft because... money.
> If your user env is compromised its too late
How to recover from a "my env was compromised" situation? Do you recommend just say good bye to this world and commit suicide?
If not, this change makes the recovery easier: I just need to (worst case) destroy the compromised device and I can be confident that nobody is hoarding a valid credential to my online banking account which they may choose to empty (again) years later.
How to recover from a "my env was compromised" situation? Do you recommend just say good bye to this world and commit suicide?
If not, this change makes the recovery easier: I just need to (worst case) destroy the compromised device and I can be confident that nobody is hoarding a valid credential to my online banking account which they may choose to empty (again) years later.
> How to recover from a "my env was compromised" situation
depends on the scope of the compromise, its an open ended question with lots of rabbit holes dependent on backups and other stuff.
but as others mentioned: logging out of all sessions is a good start from the <bank, ect> side... people should be logging out of sessions anyways when not logged on a particular sites webui.
we are at a fun time when browsers have too much access (and javascript <reminds me of Flash>) to the host system that they are themselves are the OS (its been this way for many years)... the bigger issue are the websites that dont auto logoff, that have really poor password compliance, and even worse encryption of their own systems. a compromised system also means your password vault is compromised too given that it is in the same env. a more complex solution would be to have your keepassdx on an internet-less system and your browser on another system where a user logs off explicitly, if not automatically). then syncing bookmarks and play-time and sites-ive-visited can be less of a 'my whole account session' got compromised
depends on the scope of the compromise, its an open ended question with lots of rabbit holes dependent on backups and other stuff.
but as others mentioned: logging out of all sessions is a good start from the <bank, ect> side... people should be logging out of sessions anyways when not logged on a particular sites webui.
we are at a fun time when browsers have too much access (and javascript <reminds me of Flash>) to the host system that they are themselves are the OS (its been this way for many years)... the bigger issue are the websites that dont auto logoff, that have really poor password compliance, and even worse encryption of their own systems. a compromised system also means your password vault is compromised too given that it is in the same env. a more complex solution would be to have your keepassdx on an internet-less system and your browser on another system where a user logs off explicitly, if not automatically). then syncing bookmarks and play-time and sites-ive-visited can be less of a 'my whole account session' got compromised
Log into the bank and click the "log out of all sessions" to invalidate all cookies. Or if an attacker changed your credentials walk into the back and have a banker do it and then have the show/reverse all changes and transactions the attacker made. If the option does not exist, demand they add it or you and your money will go to another bank. Not all websites have this option but they would if enough customers demanded it.
Not all applications provide users with the option to log out of all sessions.
Web Applications today, could do several things without the help of Google to make cookies more difficult to be stolen but they don't.
Web Applications today, could do several things without the help of Google to make cookies more difficult to be stolen but they don't.
This looks like a tool for Google/Alphabet to use to improve ads or make it more difficult to use unapproved browsers under the guise of 'privacy'.
An astroturf feature not unlike ManifestV3.
An astroturf feature not unlike ManifestV3.
Call me insane but I feel like that's just a rebrand of WEI or will evolve into WEI.
Just like everyone hated FLoC and when Google introduced Privacy Sandbox everyone was silent about it.
This is going to lock down the web considerably. A lot of tools like those that download videos rely on being able to export your browser cookies and use them to establish a session in your cli tool.
Just makes it more annoying to implement. Your locally running CLI tool will still have access to the local TPM the browser used: in other words, the CLI tool can implement the necessary parts of the browser.
Personally I do not believe this for a second. Yes I do believe that this is what they will do now. But in a few years, if DBSC becomes mainstream? I fully believe Google will start abusing this to strengthen their control. It's the same with the Chrome browser that they eventually used to push MV3 and tried to push WEI.
Honestly? I feel that this could be their way of pushing WEI again through the back door, and I am concerned that unlike WEI, this seems to barely get any buzz or pushback from the community.