Google bakes new cookie strategy that will leave crooks with a bad taste
- Reference: 1712146097
- News link: https://www.theregister.co.uk/2024/04/03/google_cookie_strategy/
- Source link:
Cookies are still widely used by websites, which get the browser to save information on a session locally to a small file (the cookie) stored on the computer to keep users signed in and store their site preferences.
But malware can target cookies, simply copying them from the user's hard drive and sending them back to a remote attacker, who can then potentially use the session information in the cookie to access user data from the websites they are associated with.
[1]
Now Google says it is working on a new web capability it dubs Device Bound Session Credentials (DBSC) to combat this threat. The idea behind this is to use a cryptographic key to tie a session to the user's specific computer or device.
[2]
[3]
"By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value. We think this will substantially reduce the success rate of cookie theft malware," said Kristian Monsen of the Chrome Counter Abuse team, writing on Google's [4]Chromium Blog .
It is expected to work like this: when the browser starts a new session, it creates a new public/private key pair locally on the device, and then gets the operating system to safely store the private key. Google says that its Chrome browser will use facilities such as a Trusted Platform Module (TPM) for that.
[5]
The DBSC API allows a web server to associate a session with the public key generated, and the session can be periodically refreshed with cryptographic proof the session is still bound to the original device. This is performed out-of-band from regular web traffic, and only if the user is actively using the session.
According to Google, privacy is protected because each session is backed by a unique key and DBSC does not enable sites to correlate keys from different sessions open on the same device. The only information sent to the server is the per-session public key which the server uses to certify proof of key possession.
[6]Google will delete data collected from 'private' browsing
[7]Rust developers at Google are twice as productive as C++ teams
[8]Miscreants are exploiting enterprise tech zero days more and more, Google warns
[9]Google's AI-powered search results are loaded with spammy, scammy garbage
Google expects the Chrome browser will initially support DBSC "for roughly half of desktop users," based on the current hardware capabilities of the machines out there. For example, not all computers have a TPM, but they are likely to become more common since Microsoft made one a requirement to run Windows 11, and there are software-based alternatives.
"We may consider supporting software keys for all users regardless of hardware capabilities. This would ensure that DBSC will not let servers differentiate between users based on hardware features or device state," Monsen said.
This is all very well, but DBSC is unlikely to catch on if only Google implements the technology. According to Monsen, interest has been expressed by others in the industry, including identity providers and even Microsoft for its own Edge browser. Google is also developing the project in the open on [10]GitHub , with the goal of becoming an open web standard, he added.
[11]
For those interested, an explainer is available in the [12]GitHub README for the project.
Google said that DBSC will be "fully aligned" with its [13]phase-out of third-party cookies in Chrome , and said it is currently experimenting using the tech to protect some Google Account users running Chrome Beta.
"This is an early initiative to gauge the reliability, feasibility, and the latency of the protocol on a complex site, while also providing meaningful protection to our users," Monsen said.
"When it's deployed fully, consumers and enterprise users will get upgraded security for their Google accounts under the hood automatically. We are also working to enable this technology for our Google Workspace and Google Cloud customers to provide another layer of account security."
Readers with long memories may recall that Intel once tried to pitch a unique [14]processor serial number (PSN) embedded in each CPU, claiming similar security benefits, but it was forced to discontinue this when a row erupted over the possibility for the serial number to be used to track users online. ®
Get our [15]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zg19HqJmZXS48Gx63GU64gAAAAk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zg19HqJmZXS48Gx63GU64gAAAAk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zg19HqJmZXS48Gx63GU64gAAAAk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zg19HqJmZXS48Gx63GU64gAAAAk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2024/04/01/google_will_delete_data_incognito/
[7] https://www.theregister.com/2024/03/31/rust_google_c/
[8] https://www.theregister.com/2024/03/27/surge_in_enterprise_zero_days/
[9] https://www.theregister.com/2024/03/25/googles_aipowered_search_results_are/
[10] https://github.com/WICG/dbsc
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zg19HqJmZXS48Gx63GU64gAAAAk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] https://github.com/WICG/dbsc/blob/main/README.md
[13] https://www.theregister.com/2024/01/04/google_set_to_start_cookie/
[14] https://www.theregister.com/2000/05/04/so_farewell_then_intel_psn/
[15] https://whitepapers.theregister.com/
Re: Seriously, author?
Would that be an advertising id by another name?
Re: Seriously, author?
Edge is based on Chromium; Chrome itself contains all kinds of Google-specific stuff.
I'm not 100% confident but the implementation looks like a reasonable mitigation against session-stealing. I don't think that a single pair of keys is the idea: amongst other things, this would make tracking a lot easier. But also, if the validation is happening on the client then public keys are only exposed when the cookie is first set up. However, it might still be possible to cause trouble if the public key can be intercepted and, therefore, reused at the right moment.
And, if the implementation degrades reasonably, it can be provided when supported, dropping down to other mechanisms when its not.
Re: Seriously, author?
There's a little more detail [1]here .
The proposal is essentially that at the point at which a user "logs in" (or equivalent) to a website (it doesn't apply to unauthenticated sessions) the browser is prompted to generate a private key which is used to secure session cookies. That private key is then destroyed when the user "logs out" (or equivalent) or when the browser quits. Since the private key isn't reused, then there shouldn't be a privacy issue - however, since the key is tied to a "log in", then you're not talking about an anonymous user in any case so that's all really moot.
There's nothing inherently that requires a TPM - it would clearly have some potential benefit simply using a software key vault of some kind, but with greater risk of malware exfiltrating the keys and transparently continuing the session on another device. Though TPMs are not quite as inflexible as might be supposed by the time the OS has built an environment around them - assuming you have one to hand.
I think the big problem with the Google proposal is that it's essentially a hack: it requires the browser to periodically refresh its credentials (to prove it still has the private key) by making an http request to a specific URL associated with the application. Unlike, for example, [2]Token Binding which is a proposed extension to TLS that is transaparent in that it doesn't depend on upper-layer application behaviour. The somewhat questionable justification for Google's approach is that in typical web application infrastructures, the security context (TLS connection) has been stripped by some border device and is unavailable to the web application code. And justifying your security hack on the basis that you junked all the security data you had at the earliest possible moment is very typical of modern practice, but I can't help feeling a better solution might be available.
[1] https://github.com/WICG/dbsc/blob/main/README.md2
[2] https://github.com/WICG/dbsc/blob/main/README.md
I thought the idea of cookies was to maintain state on the client so that the server could be stateless. if the server is now having to maintain state (half of a key pair) why use anything else on the client? Or is that the whole point and I've missed it somewhere?
Session ID cookies (mostly) operate in the exact opposite way, they provide a key to a server side session store, and are the most common way of providing a user login. You can use client side sessions, where the session data is encoded and stored in a cookie, but this has limits on state size, and the state is visible to the end user - they can't modify the state, as it will be signed/protected by hashing the encoded session data combined with a server side secret.
Quite simple to defeat with malware
Just like any in-browser malware that tampers with HTML/JS/CSS content by modifying chrome.exe memory, just hook the TPM negotiation function and get the keys/cookies in cleartext, replacing the public/private keys with your own. Then exfiltrate the cookies in cleartext to your C2.
Just like the Prilix malware does with POS systems.
Any more genius ideas from Google?
Seriously, author?
The Microsoft Edge browser is Chrome...
Also, how is Chrome going to get write access to the TPM? Am I going to have to repeatedly lock and unlock the TPM to allow Chrome (which is configured to clear the cache on exit) to create a new keypair every time its restarted?
Additionally, for those users who don't clear their cache on exit, won't having a single for-Chome public/private key pair make user tracking so much easier?
Sounds to me like this is the LAST thing any sane person would want.