Security

647 readers

5 users here now

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

Rules :

All instance-wide rules apply.
Keep it totally legal.
Remember the human, be civil.
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

Chromium developing device bound session tokens to combat session token theft techniques (blog.chromium.org)

submitted 6 months ago by [email protected] to c/security

4 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 6 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 0 points 6 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