Show HN: WebSession, a Secure Replacement for Cookies
websession.dev
Show HN: WebSession, a Secure Replacement for Cookies
1–10 of 113 posts
Re: Show HN: WebSession, a Secure Replacement for Cookies
#2Not going to comment on the technical merits of this proposal because it's not my area of expertise but as a user I look at any proposal in this space with extreme caution (because most of the time "the man" really is out to "get you" - see "Web Environment Integrity").
I'm a big fan of Firefox's Total Cookie Protection and make extensive use of the "Temporary Containers" extension, so I will likely disable this feature as well if it becomes standard because it eventually boils down to making tracking easier.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#3Seems like a good proposal to me. Maybe there are privacy/security holes?
Is it sort of like a "rich mans" CSRF token, but you don't need to put it in the form, and it works on all requests GET, POST, ..., and is cryptographically secure etc.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#4This seems like a great way to pull out session identity from cookies and sidestep a lot of the baggage there.
I would caution framing it as a secure replacement for cookies, it’s a secure replacement for session ID token cookies. Tons of cookies aren’t just opaque IDs.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#5DPoP[1] is on its way and already starting to see adoption by identity providers like Okta[2] (oh, the comedy). It's unfortunately specific to OAuth, so narrower in terms of application, but will cover how most web apps work today.
2. https://www.okta.com/blog/2023/06/a-leap-forward-in-token-se...
Re: Show HN: WebSession, a Secure Replacement for Cookies
#6Great overview of cookie's shortcomings, and thank you very much for the solution.
By the way, the Github link at the top of the page is 404.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#7Seems complicated. Seems like what is desired here is some sort of shared secret. Then use it to generate a sequence of session ids.
Feels like there is a similar algorithm to get that than what is proposed here
Re: Show HN: WebSession, a Secure Replacement for Cookies
#8Not going to comment on the technical merits of this proposal because it's not my area of expertise but as a user I look at any proposal in this space with extreme caution (because most of the time "the man" really is out to "get you" - see "Web Environment Integrity"). I'm a big fan of Firefox's Total Cookie Protection and make extensive use of the "Temporary Containers" extension, so I will likely disable this feat…
This would be more akin to being logged in to a specific site with a JWT than to tracking writ large. Basically, if your site has access to this secure key, then it already knows who you are (i.e. because you are logged in). This key would never be shared with third-party sites and doesn’t introduce any novel ways of doing so. You could clear the token by clearing website storage or disabling JavaScript.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#9The only thing in this protocol that prevents the reuse of Authorization header is keeping track of nonce:
> Validating that the nonce has not been used already for this session. Important: at this point, the nonce should be added to the ‘seen’ set, because nonces should be invalidated whether the signature validation passes or fails. Failure to do so can allow attackers to brute-force a valid signature for a single nonce.
That's one extra db row / kv pair for every single request, including read requests, for very little benefit.
Request signatures incorporating timestamp and optionally path/payload are stronger, can be statelessly validated, and are already in use today on certain sites.
Re: Show HN: WebSession, a Secure Replacement for Cookies
#10I’d like to understand the threat model under which this is supposed to be superior to a bearer token stored in a heavily restricted (__Host- prefixed, Secure, HttpOnly, SameSite=Lax) cookie. Neither can be exfiltrated by JavaScript so they’re in pretty much the same spot as far as XSS is concerned. Both can be captured if the user agent is compromised so there’s no difference there AFAICT. Is interception of traffic or errant logging really a big source of compromised bearer tokens?