this post was submitted on 14 Apr 2024
16 points (80.8% liked)

Security

633 readers
2 users here now

A community for discussion about cybersecurity, hacking, cybersecurity news, exploits, bounties etc.

Rules :

  1. All instance-wide rules apply.
  2. Keep it totally legal.
  3. Remember the human, be civil.
  4. Be helpful, don't be rude.

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
LinearArray@programming.dev
16
Chromium developing device bound session tokens to combat session token theft techniques (blog.chromium.org)
submitted 7 months ago by testeronious@lemmy.world to c/security@programming.dev
4 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] onlinepersona@programming.dev 1 points 7 months ago (2 children)

Sounds like a tracking nightmare, right off the bat. There is absolutely no way this will not be used for tracking.

Each session is backed by a unique key and DBSC does not enable sites to correlate keys from different sessions on the same device, to ensure there's no persistent user tracking added. The user can delete the created keys at any time by deleting site data in Chrome settings. The out-of-band refresh of short-term cookies is only performed if a user is actively using the session (e.g. browsing the website).

DBSC doesn’t leak any meaningful information about the device beyond the fact that the browser thinks it can offer some type of secure storage. The only information sent to the server is the per-session public key which the server uses to certify proof of key possession later.

All nice and dandy, but what constitutes a session? If you want people to stay logged in after killing the browser, that has to be stored somewhere.

I have absolutely no faith in this. And if there's malware that has the same rights as the browser, how will the TPM help? This is a serious question. How will the TPM help?

Anti Commercial-AI license

[–] Tramort@programming.dev 1 points 7 months ago

You are smart to be skeptical of Google's intentions, but it seems like it is possible to make an implementation without the problems you identified.

[–] JakenVeina@lemm.ee 1 points 7 months ago (1 children)

The TPM stores the private key and doesn't hand it out to anyone, not even the browser. Malware can no longer "exfiltrate" the whole session. I.E. if a piece of malware manages to compromise a cookie, it can send it off-device, where it can be freely used to impersonate the user. With the TPM involved, any impersonation of the user has to be done locally on the same device, which is theoretically more difficult to do than just silently steal a cookie.

I'm on board with you, though, in being skeptical here.

[–] onlinepersona@programming.dev 0 points 7 months ago

The article specifically talks about malware running on the host machine. If that is happening, how is a TPM supposed to help?

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

Great, the browser generates a key pair and puts the private key in the TPM. So the malware sits between the browser and the TPM. How is that better? Even if the private key were generated on the TPM, what stops malware from impersonating chrome or hooking into chrome?

I can't help but think it's security theatre to add another tracking mechanism behind the scenes.

Anti Commercial-AI license