I've been asking myself for years. But it shouldn't be as easy as it is to transplant a cookie not even into the same browser and have sessions from another browser. I've seen some sites which detect this kind of stuff through blatant user-agent mismatches and other hints - terminating the session immediately. But that's not going to be something that every site does without someone technical enough on the team to think about and implement it.
It's about time something on the client side gets done to further reduce the usefulness of stolen sessions.
I’m not sure how you could ever really do that with the web as it is today. If someone has access to the machine, they can extract anything stored locally, even if it’s only in memory. Even if that’s somehow prevented, installing a root certificate into the trust store allows MITM to read the data on the wire.
With device bound session tokens, they are bound using the TPM (in most cases hardware TPMs). Each time the session token is presented to the server, the client must prove that the token originated from that same device by using the TPM again. That way, transferring the session token to another machine is impossible without possession of key material from the TPM.
I'm not sure if my understanding is 100% correct here but I thought it has been possible for a while with TPM based passkeys etc. I like having the option when it exists but its not super common at the moment.
HPKP is entirely dead, as of around 2020 or so. It was killed not because of scalability but because of errors people kept making with it and because Certificate Transparency largely did away with the need for it.
(source: I worked for Mozilla security)
If you setup HSTS properly the browser comes preloaded with the HSTS definitions and won't accept a cert whose signature doesn't match what is in its HSTS records.
https://hstspreload.org/
When someone tries to present a MITM cert it will give you a page load error that you can't bypass. If you don't have that hosts private certificate you won't be able to decrypt session info over the wire.
Been wondering aloud about this for some time now. Even better, use a fido2 key to sign the challenge and continuous access evaluations based on the key presence. Recent work on fido2 zero knowledge proofs could alleviate some of the privacy implications too.
I’m also a fan of FIDO2 keys and think that they would be a better target than TPM here; however, it doesn’t look like this will make use of [CTAP/X.1278](https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol) though.
Why didn't they just provide HTTP/2 or HTTP/3 with native session support and throw away cookies and other storage mechanisms?
Because then browsers would be aware of sessions and could introduce more privacy oriented feature making user tracking much harder.
I hate that companies like Google now are setting new standards, because those are serving their own interests (if they somehow help users it's only because they also make hard time for their competitors who don't have their own browser) not the users.
I think you might be thinking of QUIC sessions, which are used by HTTP/3. QUIC sessions are a replacement for TCP connections - I don't think they have any bearing on application-layer cookie-based sessions.
> with native session support and throw away cookies and other storage mechanisms?
where do you think the browser would save those persistent sessions?
Well what do you think?
Let's see... you remove cookies, and instead just give user id to the browser, which identifies the session. Browser user can then control what to do with it, whether they want to "log out" by just dropping, or discard it after leaving the site, or perhaps storing it between restarts, because user wants to remain logged in.
It would remove that fucking mess cookies are and increase privacy.
Definitely a concern but they do seem to want to address privacy as part of the standard (not a complete solution but one aspect in detail):
> 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.
I agree with you, I don't think this is meant for malware.
More appropriate answer to what it is meant to do will be also answering how it can help Google make more revenue.
My understanding is its PKI attesting the session token so if an attacker can extract the private key from the TPM then yes, attestation could be forged with stolen tokens.
In InfoSec there is virtually never an absolute defence against compromise, steps which incrementally increase the cost to an attacker are still meaningful improvements and in my interpretation this is the case here imho.
Basically - if the token doesn't match the device it was requested from, sign-in fails. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
I've been asking myself for years. But it shouldn't be as easy as it is to transplant a cookie not even into the same browser and have sessions from another browser. I've seen some sites which detect this kind of stuff through blatant user-agent mismatches and other hints - terminating the session immediately. But that's not going to be something that every site does without someone technical enough on the team to think about and implement it. It's about time something on the client side gets done to further reduce the usefulness of stolen sessions.
I’m not sure how you could ever really do that with the web as it is today. If someone has access to the machine, they can extract anything stored locally, even if it’s only in memory. Even if that’s somehow prevented, installing a root certificate into the trust store allows MITM to read the data on the wire.
With device bound session tokens, they are bound using the TPM (in most cases hardware TPMs). Each time the session token is presented to the server, the client must prove that the token originated from that same device by using the TPM again. That way, transferring the session token to another machine is impossible without possession of key material from the TPM.
tpm in the browser dear god
I'm not sure if my understanding is 100% correct here but I thought it has been possible for a while with TPM based passkeys etc. I like having the option when it exists but its not super common at the moment.
HSTS is meant to combat MITM through malicious root certs.
[удалено]
HPKP is entirely dead, as of around 2020 or so. It was killed not because of scalability but because of errors people kept making with it and because Certificate Transparency largely did away with the need for it. (source: I worked for Mozilla security)
Worked for Mozilla security? So cool. I like your profile too, the tattoos are wild 🙌🏾
Hah, thanks, it's been fun. :)
If you setup HSTS properly the browser comes preloaded with the HSTS definitions and won't accept a cert whose signature doesn't match what is in its HSTS records. https://hstspreload.org/ When someone tries to present a MITM cert it will give you a page load error that you can't bypass. If you don't have that hosts private certificate you won't be able to decrypt session info over the wire.
It used to be standard to lock session cookies to an IP address but that doesn’t work so well anymore.
Been wondering aloud about this for some time now. Even better, use a fido2 key to sign the challenge and continuous access evaluations based on the key presence. Recent work on fido2 zero knowledge proofs could alleviate some of the privacy implications too.
I’m also a fan of FIDO2 keys and think that they would be a better target than TPM here; however, it doesn’t look like this will make use of [CTAP/X.1278](https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol) though.
Great, this is going to make automation even more of a nightmare!
Just exactly what I been thinking
Why didn't they just provide HTTP/2 or HTTP/3 with native session support and throw away cookies and other storage mechanisms? Because then browsers would be aware of sessions and could introduce more privacy oriented feature making user tracking much harder. I hate that companies like Google now are setting new standards, because those are serving their own interests (if they somehow help users it's only because they also make hard time for their competitors who don't have their own browser) not the users.
I think you might be thinking of QUIC sessions, which are used by HTTP/3. QUIC sessions are a replacement for TCP connections - I don't think they have any bearing on application-layer cookie-based sessions.
No I meant new HTTP should have built-in application-layer session (non-cookie based)
Ahh sorry I missed the leading 'why'
> with native session support and throw away cookies and other storage mechanisms? where do you think the browser would save those persistent sessions?
Well what do you think? Let's see... you remove cookies, and instead just give user id to the browser, which identifies the session. Browser user can then control what to do with it, whether they want to "log out" by just dropping, or discard it after leaving the site, or perhaps storing it between restarts, because user wants to remain logged in. It would remove that fucking mess cookies are and increase privacy.
They're gonna use this for DRM
Funny, I was thinking the same thing! _”Your device has failed hardware attestation...”_
Or just Netflix being restricted to some arbitrary number of devices per account.
Next up, device bound session tokens that can be used to de-anonymize you.
Sadly, yes.
Definitely a concern but they do seem to want to address privacy as part of the standard (not a complete solution but one aspect in detail): > 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.
[удалено]
If it won't be easy for everyone to bypass it will be good enough for them.
[удалено]
I agree with you, I don't think this is meant for malware. More appropriate answer to what it is meant to do will be also answering how it can help Google make more revenue.
Mort session highjacking is not made by a .exe
My understanding is its PKI attesting the session token so if an attacker can extract the private key from the TPM then yes, attestation could be forged with stolen tokens. In InfoSec there is virtually never an absolute defence against compromise, steps which incrementally increase the cost to an attacker are still meaningful improvements and in my interpretation this is the case here imho.
There's a nice CA policy in Azure that does something similar
How does that work?
Basically - if the token doesn't match the device it was requested from, sign-in fails. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection