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

101–110 of 113 posts

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

#101

Post by paulgb »

maxloh wrote: post #96
paulgb wrote: post #72

Earlier quoted context omitted.

The proposal says that server-side expiration is still required. The ability to request that the client delete the token when the computer is locked is purely additive; if the client does not honor it, at worst you just get something equivalent to the status quo with cookies. If the client works correctly, you get a security feature that is currently impossible with cookies (wiping the session as soon as the laptop l…

It is possible currently. Just attach an `beforeunload` listener which asks the server to invalidate the current session.

I just tried it (Chrome on Mac), and beforeunload is not called when I lock the machine. The MDN docs also don't suggest that it should be.

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

#102

Post by chrismorgan »

psd1 wrote: post #54
grammers wrote: post #44

Cookies are not really about security, but privacy. Their tracking of your online habits are bad; how would that change with WebSessions?

I don't clear cookies because session cookies are useful. If cookies are never session cookies, then I can treat all cookies as useless.

A proposal like this will never fully replace cookies: quite apart from inertia and largely-unmaintained systems, it’s much, much more complicated for servers to implement. Diffie-Hellman, CBOR, encryption, session nonces… now compare that to just generating a big random string and using that as a cookie value and as the session table primary key. The consequence is that—even if there’s a nice backwards-compatibility path and all the browsers implement the whole lot—major frameworks like Django or Ruby on Rails will implement it, but smaller things and roll-your-own things won’t, because they’ve already got something easier that works about as well.

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

#103

Post by dcow »

kardianos wrote: post #81
zacharyvoase wrote: post #51

Hi! Author of this proposal here. I’m loving all the feedback and wanted to address some things: * Yes, nonce tracking is expensive. HTTP request signatures could be used instead of nonces—they’re just not fully fleshed out yet, from what I can tell. And a lot of other crypto systems we rely on in Web traffic today also assume proper nonce tracking. Fortunately you only need to track distinct nonces per established s…

Noces are a non-starter for me. You cite trivial issues such as setting flags on a cookie, then go on to require checking nonces for uniqueness. You know what most people would do? They would ignore the expensive nonce check. This would turn this into an expensive client generated opeque token. How would you handle sites setup with sub domains? Reading between the lines, it sounds like you want a alternative session…

I found Big Cookie. I mean seriously sitting in-front of you is a proposal that’s objectively better than session tokens in a cookie jar, where the nonce portion could be entirely optional at the expense of allowing replay attacks, and you call it a non starter. You’re just looking for reasons to not be secure at this point.

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

#104

Post by dcow »

kardianos wrote: post #82
zacharyvoase wrote: post #51

Hi! Author of this proposal here. I’m loving all the feedback and wanted to address some things: * Yes, nonce tracking is expensive. HTTP request signatures could be used instead of nonces—they’re just not fully fleshed out yet, from what I can tell. And a lot of other crypto systems we rely on in Web traffic today also assume proper nonce tracking. Fortunately you only need to track distinct nonces per established s…

Trying again to be more constructive, rather than having a nonce, make the nonce meaningful, so there is a time component, such as seconds from initiating the session, and a validation portion that shows this came from the session function and attests the time portion is valid. Then nonce storage, if you do it, can be limited to window when it is valid.

Yeah clocks might be a necessary evil that makes storage-free nonces a reality. Feels like a plausible compromise.

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

#105

Post by paradite »

zmxz wrote: post #39
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 dow…

There are valid use cases and complex interactions between multiple systems where the only solution is client handling of user token.

Also, sessionStorage is a web standard and it is designed to store data to be used in the session. If you think frontend devs shouldn't use it because they are incompetent at handling XSS, then maybe backend devs should also not use databases because they might leave the port open to public internet.

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

#106

Post by paradite »

nneonneo wrote: post #38
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.

It's just an HTTP header, I'm sure frontend devs will be polyfilling the implementation before the browsers, if this were to be the standard.

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

#107

Post by zacharyvoase »

porridgeraisin wrote: post #13

The only real advantage I see here is having a dedicated storage for session identifiers as opposed to clubbing it with other non-essential cookies. Everything else in the proposal isn't really required. Considering this, simply choosing a standard name for session cookies suffices. Browsers can give an option to the user to rejects all cookies that don't have the name "WebSession". This is already achievable using e…

I'd argue that doing proof-of-possession for state maintenance/session persistence, rather than simple bearer tokens, is sorely needed.

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

#108

Post by patmcc »

dcow wrote: post #34
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.

Has to pwn your DNS and SSL, you mean. If someone has broken that, they'll get my credentials when I have to login at some point.

This seems to help mostly against servers improperly using cookies, servers improperly logging request content, and users improperly uploading HAR files that include bearer token.

And anyone who does those things improperly will also implement WebSession improperly - like not bothering to keep track of nonces - so what does it really gain us?

edit: just broadly on "pwn your machine vs pwn your DNS" - overall, in the general case, machines are much much easier to pwn.

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

#110

Post by dcow »

patmcc wrote: post #108
dcow wrote: post #34

Earlier quoted context omitted.

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.

Has to pwn your DNS and SSL, you mean. If someone has broken that, they'll get my credentials when I have to login at some point. This seems to help mostly against servers improperly using cookies, servers improperly logging request content, and users improperly uploading HAR files that include bearer token. And anyone who does those things improperly will also implement WebSession improperly - like not bothering to…

Yes, but this presumably still runs on top of DNS and SSL and an attacker can exfiltrate a bearer token all the same if they pwn your machine. What this does is make the only viable attack vector the one where they're on your machine or getting you to unwittingly run stuff on their behalf on your machine.
Post reply on HN