Google debuts device-bound session credentials against session hijacking | Hacker News Reader

Google debuts device-bound session credentials against session hijacking

feistyduck.com

59 pointsspeckx62 comments

A few years ago I would read this headline with hope and excitement about technological innovation.

Right now, I am apprehensive about anything Google related. Even about anything big tech related. How is this going to be used to limit our rights and track all our movements?

It turns out Google really is evil. Surprise!

The first sentence

> HTTP cookies were never intended for session management

Seems odd. IIRC that's exactly what they were meant for. State management for http which is stateless. Am I missing some history here?

> This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

RFC 2965, make of it what you want but I agree with you. Actually, RFC 2109 is even older (1997) and says more or less the same.

I could be wrong, but I believe the author is referring to cookies being used for session authentication as opposed to general session management.

That's still exactly what they they were invented, though. The very first example in RFC2109 is literally for tying a session to a login.

The "abstract idea" of a cookie is an identifier that it lets a server consider requests within a larger series of requests by the same person, but the fact that it can do that at all also meant that it solved the whole "how do we know whether this user is logged in without every page request after login needing to be a POST that includes the user's name and password again".

I'm starting to look at every technology change Google makes as a way for them to entrench their moat.

The faster we get an antitrust breakup of Google from Chrome and Android, the better.

There’s going to be a lot of LinkedIn scrapers and tools that are going to stop working if LinkedIn adopt this - a lot of these tools work off particular session cookies you share with them

If it's your TPM, the tools should be able to be authorized for signing too.

Defending against account takeovers with passkeys and DBSC (11 points, 1 month ago) https://news.ycombinator.com/item?id=44725402

Chrome Origin Trial: Device Bound Session Credentials (85 points, 4 months ago, 80 comments) https://news.ycombinator.com/item?id=43865379

Device Bound Session Credentials Explainer (14 points, 2024, 5 comments) https://news.ycombinator.com/item?id=39926961

The article claims this is based on Token Binding, but skimming the W3 spec it seems to be something entirely different and not at all to be based on or related to TLS Token Binding (with an integration already envisaged by the WebAuthN spec). TB doesn't need or rely on a TPM at all, it conceptually just ties bearer tokens to a key which is (re-)used across TLS sessions; for upper layers this is transparent, but for attackers it makes it much harder to use exfiltrated tokens.

It is not based on TB but it is heavily informed by those efforts. See here: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...

However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.

Funny how we're going back to AOL times: fenced off network, pay-to-play. We've required ISPs to play fair though net neutrality only to have similar barriers put in place a decade later by upstream software incumbents.

I 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...

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.

We're still in the infancy of agentic AI, but I imagine that in the next few years, it's going to be more important to be able to grant an agent your credentials to perform operations on your behalf. Basically, you want the agent to be able to do all the same things you can do. But perhaps the agent doesn't live on your local device. I'm not saying that DBSC isn't beneficial, but I think we also need to be thinking of ways to grant AI agents permissions that used to be solely tied to the user's session.

I 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

How long are the public keys? >160 bits and that's futile.

If TPM is used then the regular session cookies are also secure, just in a different way. One can use hardware based attestation to tie the session token/cookie to the device and so they cannot be stolen or forged.

DBSC will run into all the same problems on platforms that don’t support TPMs. Not sure how this is changing the landscape. It’s just another implementation of the same thing.

I'm not sure I follow your point: how would a web service provider use a user's TPM in a pre-DBSC world? "Use hardware based attestation to tie the session token/cookie to the device" is pretty much exactly what DBSC does.

DBSC is intended to be deployed opportunistically alongside regular cookies, so users on devices without TPMs just won't benefit from the additional protections that DBSC provides.

Unless you're paying me a lot of money (and even then) I WILL NOT MAINTAIN AN HSM FOR YOUR SERVICE. PLEASE FUCK OFF.

If you cared about security you would let me authenticate with ssh key signatures. GitHub does this, if you can manage to talk to an HSM you can manage to talk to the openssh agent.

This so much, it's all about locking people to their hardware and walled gardens.

[flagged]

This has no connection with reality. This is not an attestation mechanism, and can't be used as one.

Yes it absolutely is and will be used as such, this is EXACTLY how google play remote attestation works and a necessary building block for doing it in the browser. It is the exact reason why microsoft and google are pushing for tpms in windows 11 and it's already a reality on android and every grapheneos user knows the pain[0] and is the absolutely logical next step.

[0] https://grapheneos.org/articles/attestation-compatibility-gu...

I read that not as a claim that this is an attestation mechanism, but that this is another step towards that. Given that Google has previously discussed implementing the Web Integrity API, it's not so large a leap as to be dismissed as disconnected from reality.

It's clearly a link in the chain.

Yes but the commenter has referred to you as a stock animal, therefore he automatically wins the debate. Sorry, I don't make the rules.

What negative effects are you thinking DBSC will cause?

The very next step they will take is that they will only give devices session credentials that pass remote attestation, preferably to the browser level. Than you won't be able to use alternative clients or extension google doesn't deem acceptable.

(engaging in good faith...)

What's preventing alternative clients from doing that?

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.

~~~~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?

> why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side

That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.

Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...

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.

> valuable security improvements

Valuable to who, exactly?

To everyone who has ever had session creds stolen? Right now any malware which can read your disk has a gigantic backdoor around MFA, do you not find that a problem?

If you have malware that can read your disk, then you have bigger issues than MFA?

In other words - focus on solving the real issue (ability to give more fine-grained permissions to programs) rather than restricting the ability of users to do what they want with credentials they already have on hardware they control.

To everyone who uses computers.

> we need things like this.

Speak for yourself, Kemosabe.

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.

I am glad I got to experience the internet before this. It seems sadly inevitable. What was once built by and for the people has been taken over by the interests of the rich and powerful.

Could you please stop posting flamebait and snark? Your account has unfortunately been doing this repeatedly. It's not what this site is for, and destroys what it is for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

You're of course welcome to make your substantive points more thoughtfully.

You know what dang, I'll genuinely consider it.

I truly believe that we'll see a world where everything requires remote attestation and corporate approved devices within the next few years. It's a nightmare scenario for me and I consider it inevitable. I just don't have much more than sad cynicism left since it seems to become worse every day.

Your genuine consideration is appreciated!

I hear you about this issue (corporate control over devices, let's call it) and of course a large segment of the community agrees with you. Howwever, the moderation point here isn't about that; it's about a style of commenting that we're trying to avoid here. Your account has been posting in that style on unrelated issues too, so I think this is independent of the specific content.

I 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.

One man's session hijacking is another man's unofficial third party client support.

"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!)

Most session hijacking is via JavaScript, so even malware-extractable browser-TPM would help a lot!

You can use js-nonextractable keys for auth today, no new specs needed.

This will break and fracture the web. Unfortunately many here have much to lose by criticizing google. I have just spent 8 hours today updating my apps on the google play store, answering business emails on my google email account and updating customer tracking data on google analytics and updating their google ads.

If they decide to make an example out of me, to teach the rest of you how to behave, I am screwed. I guess that's the "freedom" you US based folks are talking about. This has already been affecting the discourse on sites like HN for a while.

If you get creative and find a way to sell yourself into slavery despite us making that nominally illegal there's very little we can do to help you.

Reply on news.ycombinator.com