See also: RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
https://datatracker.ietf.org/doc/html/rfc9449
The spec doesn't say where you store the key material, but you could reasonably put it in a TPM.
Google debuts device-bound session credentials against session hijacking
21–30 of 71 posts
Re: Google debuts device-bound session credentials against session hijacking
#22I hope it catches on! Though they suggest storing the signing keys in TPM which is ideal, even storing them locally in the browser in an unextractable manner would be enough to prevent session hijacking.
"unextractable" from the perspective of the JS-facing APIs does not necessarily mean unextractable by local malware (unless it's backed by something like a TPM!)
Re: Google debuts device-bound session credentials against session hijacking
#23[flagged]
This inexplicable overreaction to genuinely valuable security improvements is getting ridiculous. Computer security is a complete dumpster fire right now and we need things like this.
Re: Google debuts device-bound session credentials against session hijacking
#24Earlier quoted context omitted.
You can run a software TPM if you browse within a VM.
And that Software TPM has whos vendor endorsement keys exactly? Ah yes, ones that google won't consider valid.
Well, it's a good thing Device Bound Session Credentials (DBSC) as proposed here has no way to actually send said endorsement key anywhere; rending the objection irrelevant. The TPM is only for secure storage as verified by the browser itself, not the website being visited.
Re: Google debuts device-bound session credentials against session hijacking
#25[flagged]
You can run a software TPM if you browse within a VM.
~~~~But your VM TPM won't be signed during manufacturing by a trusted root. No attestation.~~~~
OK I take it back, privacy is one of their specified goals:
> Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.
However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?
Re: Google debuts device-bound session credentials against session hijacking
#26I think Microsoft has also been working on this and protected resources using Conditional Access can enforce a requirement for DBT?
https://learn.microsoft.com/en-us/entra/msal/javascript/brow...
Re: Google debuts device-bound session credentials against session hijacking
#27I think the DBSC is on the right direction but while it generates separate keys per session to prevent cross-session tracking (Google's ultimate ad dream), the spec acknowledges a critical vulnerability: malicious sites can collaborate by attempting to guess public keys until they find matches, creating persistent cross-site user identifiers, essentially weaponizing the security feature into the ultimate tracking system that survives cookie deletion and VPN usage
Re: Google debuts device-bound session credentials against session hijacking
#28Re: Google debuts device-bound session credentials against session hijacking
#29[flagged]
You seem to spend most of your time on HN saying the cattle are meeting the butcher, or saying fsck responsible disclosure, or other hot takes.
Re: Google debuts device-bound session credentials against session hijacking
#30Earlier quoted context omitted.
And that Software TPM has whos vendor endorsement keys exactly? Ah yes, ones that google won't consider valid.
Well, it's a good thing Device Bound Session Credentials (DBSC) as proposed here has no way to actually send said endorsement key anywhere; rending the objection irrelevant. The TPM is only for secure storage as verified by the browser itself, not the website being visited.
[flagged]