Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: WebSession, a Secure Replacement for Cookies

websession.dev

Post reply on HN
Print view View original

31–40 of 113 posts

Re: Show HN: WebSession, a Secure Replacement for Cookies

#31

Post by oefrha »

apitman wrote: post #21
oefrha wrote: post #9

The 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…

Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

What clock attack? You validate the timestamp on the server and reject if the timestamp is too far off. The same request being repeatable within say 30s isn’t a problem in 99% of cases.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#32

Post by dcow »

oefrha wrote: post #9

The 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…

Yeah I think the proposal should add some optional binding of the web session to http resource semantics.

Also re nonces if you only keep track of active nonces and have the server return a next-nonce, or use a counter like TLS, then you avoid the ugly need to keep track of seen nonces and only need to remember currently active nonces.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#33

Post by tommiegannert »

kortex wrote: post #22
apitman wrote: post #21

Earlier quoted context omitted.

Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

That interferes with the ability to send multiple requests in-flight at the same time.

There could be a window: the last N sequence numbers are kept in a set, where N is higher than the number of concurrent requests.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#34

Post by dcow »

patmcc wrote: post #24

>>>If someone steals this cookie, they can impersonate you. Right; but with WebSession, if someone steals the client keypair (and generated shared secret), they can impersonate you just as easily. Why would this be any more secure against that? Cookies aren't perfect, for sure, but I don't think this solves it.

You can steal a bearer token just by observing the request. You can’t steal a private key by observing a signed request. With a WebSession the attacker has to pwn your machine instead of your DNS.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#35

Post by paradite »

I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie.

This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as the de facto standard of doing things.

I wonder how this compares to using sessionStorage.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#36

Post by willvarfar »

tommiegannert wrote: post #33
kortex wrote: post #22

Earlier quoted context omitted.

That interferes with the ability to send multiple requests in-flight at the same time.

There could be a window: the last N sequence numbers are kept in a set, where N is higher than the number of concurrent requests.

Doesn't the server discarding requests with the timestamp beyond a threshold already do windowing but statelessly?

Re: Show HN: WebSession, a Secure Replacement for Cookies

#37

Post by dcow »

Few things commenters are missing:

1. If you want the protocol to be “stateless” (once the session is established, that is), use a fixed, or allow any, nonce.

1.5: The proposed nonce tracking scheme is naïve but it’s pretty easy to devise alternatives and provide options (store active instead of expired nonces, nonce pool, or counter as nonce) depending on your threat model and security requirements. And sometimes naïve is all you need: if your nonces are session scoped and sessions are short (a session could be entirely ephemeral never hitting anything beyond Redis) then why not keep track of a few hundred nonces.

2. The point of this over cookies is that it is purpose built for maintaining sessions and secure by default. I’d love to turn off all cookies some day and have good sites still work normally.

3. The DH gives you asymmetric crypto meaning session token is never sent over the wire so it improves on the fundamental idea of a session in tue first place. It’s more than just a special cookie jar called websession with sane defaults.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#38

Post by nneonneo »

paradite wrote: post #35

I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie. This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as t…

The protocol does provide for fallback: if the client doesn’t understand the WWW-Authenticate: WebSession header, it can just choose to ignore it and send a request without Authorization, at which point the server can fall back to a traditional session mechanism.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#39

Post by zmxz »

paradite wrote: post #35

I know this is a replacement for cookie, but some web apps use JS and sessionStorage on browser to store session token instead of using cookie. This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser/client it means the actual browser, which would take ages to get implemented across all user agents. In which case, it would likely be polyfilled by JS first as t…

> This protocol seems to also depend on JS

It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token.

> but some web apps use JS and sessionStorage on browser to store session token instead of using cookie

This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.

Re: Show HN: WebSession, a Secure Replacement for Cookies

#40

Post by skrebbel »

unmole wrote: post #30
Beldin wrote: post #27

From the article: > As a result of increasingly strict privacy laws across the world, users are now beset with cookie banners across the Web In the words of a law prof from the Radboud University, more accurate is to say "as a result of an entire industry colluding to undermine legislation".

> as a result of an entire industry colluding to undermine legislation Asking for a friend: Is the the European Parliament also a part of the industry colluding to undermine legislation? https://www.europarl.europa.eu/

No but some agency they hired for their website it.
Post reply on HN