Google debuts device-bound session credentials against session hijacking

#1

Post by speckx » Thu, Aug 28, 2025, 2:12 PM UTC

Google debuts device-bound session credentials against session hijacking
feistyduck.com

Re: Google debuts device-bound session credentials against session hijacking

#2

Post by IlikeKitties » Thu, Aug 28, 2025, 2:28 PM UTC

[flagged]

Re: Google debuts device-bound session credentials against session hijacking

#3

Post by prasadjoglekar » Thu, Aug 28, 2025, 2:28 PM UTC

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?

Re: Google debuts device-bound session credentials against session hijacking

#4

Post by gnabgib » Thu, Aug 28, 2025, 2:29 PM UTC

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

Re: Google debuts device-bound session credentials against session hijacking

#5

Post by odie5533 » Thu, Aug 28, 2025, 2:31 PM UTC

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.

Re: Google debuts device-bound session credentials against session hijacking

#6

Post by jsnell » Thu, Aug 28, 2025, 2:32 PM UTC

IlikeKitties wrote: post #2

[flagged]

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

Re: Google debuts device-bound session credentials against session hijacking

#7

Post by odie5533 » Thu, Aug 28, 2025, 2:33 PM UTC

IlikeKitties wrote: post #2

[flagged]

What negative effects are you thinking DBSC will cause?

Re: Google debuts device-bound session credentials against session hijacking

#8

Post by alexbilbie » Thu, Aug 28, 2025, 2:34 PM UTC

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

Re: Google debuts device-bound session credentials against session hijacking

#9

Post by IlikeKitties » Thu, Aug 28, 2025, 2:35 PM UTC

jsnell wrote: post #6

IlikeKitties wrote: post #2

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

Re: Google debuts device-bound session credentials against session hijacking

#10

Post by pfortuny » Thu, Aug 28, 2025, 2:36 PM UTC

prasadjoglekar wrote: post #3

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.