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

71–80 of 113 posts

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

#71

Post by Retr0id »

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…

On the nonce-tracking front, what about a monotonic counter?

The client can generate the next nonce by incrementing the previous nonce value.

The server only needs to remember the highest nonce it's ever seen, for a particular session, and reject any new nonces less than or equal to it. O(1) in time and space, and no need for anything clever like bloom filters.

Edit: One issue I can see with this approach would be, what if requests arrive (or are processed) out-of-order? You'd perhaps want to track a small window of nonces to account for this.

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

#72

Post by paulgb »

alexchamberlain wrote: post #43
thwarted wrote: post #20

It’s also very common that a website wants credentials to be cleared when the user is inactive for a certain amount of time. This is important for sensitive applications such as banking and healthcare. Currently there’s no way to enforce that a cookie is cleared on device lock or user inactivity, especially because security requires that such cookies not be visible to JavaScript. A native session management solution…

In short, you can't rely on the client doing _anything_, especially following the protocol correctly.

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 lid closes, instead of some time after that.)

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

#74

Post by contravariant »

psd1 wrote: post #68
contravariant wrote: post #62

Earlier quoted context omitted.

Just clear all cookies after the session. That's what I do, I just need to make a couple of exceptions for the few webpages I want to remember me across multiple sessions.

Yeah, turning that on and setting the exceptions is on my to-do list...

The extension CookieAutodelete makes it fairly painless, though you do need to remember configuring it for the webpages you actually want to stay logged in to (which may be fewer than you'd expect).

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

#75

Post by red_admiral »

Retr0id wrote: post #71
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…

On the nonce-tracking front, what about a monotonic counter? The client can generate the next nonce by incrementing the previous nonce value. The server only needs to remember the highest nonce it's ever seen, for a particular session, and reject any new nonces less than or equal to it. O(1) in time and space, and no need for anything clever like bloom filters. Edit: One issue I can see with this approach would be, w…

Would this still work if the client opens more than one tab?

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

#76

Post by 3c6bYDXLMj »

archerx wrote: post #49
spiderfarmer wrote: post #47

Earlier quoted context omitted.

Still lots of sites have cookie banners because the legal department demands them, even though they are not needed for the cookies they use.

Maybe they need better legal departments that can actually read and understand laws?

[flagged]

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

#77

Post by Retr0id »

red_admiral wrote: post #75
Retr0id wrote: post #71

Earlier quoted context omitted.

On the nonce-tracking front, what about a monotonic counter? The client can generate the next nonce by incrementing the previous nonce value. The server only needs to remember the highest nonce it's ever seen, for a particular session, and reject any new nonces less than or equal to it. O(1) in time and space, and no need for anything clever like bloom filters. Edit: One issue I can see with this approach would be, w…

Would this still work if the client opens more than one tab?

As long as you have some mechanism for synchronizing state between tabs, it should be fine. iiuc, the localstorage API is synchronised, for example.

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

#78

Post by katsura »

Retr0id wrote: post #77
red_admiral wrote: post #75

Earlier quoted context omitted.

Would this still work if the client opens more than one tab?

As long as you have some mechanism for synchronizing state between tabs, it should be fine. iiuc, the localstorage API is synchronised, for example.

Except if you have two almost simultaneous requests where the request made last reaches the server first.

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

#79

Post by Terretta »

butlerm wrote: post #28
johncolanduoni wrote: post #10

I’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…

Errant logging and transfer for technical support apparently nearly lead to a security compromise at Cloudflare recently.

Or did, at Okta.

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

#80

Post by Zanfa »

jampekka wrote: post #63
latexr wrote: post #58

Earlier quoted context omitted.

I wouldn’t be so sure. Joining the cargo cult doesn’t make you immune to the law. https://noyb.eu/en/noyb-aims-end-cookie-banner-terror-and-is...

Very unlikely this will cause anybody to be fired. Will not probably even lead to company fines, nor the disappearance of the illegal dark patterns. E.g. a lot of sites used the IAB nag that was found illegal by the regulators. But IIUC only IAB had to pay a small fine and I'm quite sure nobody got fired for it because it was the "industry standard". NOYB is fighting the good fight, and without it GDPR would be even…

> NOYB is fighting the good fight, and without it GDPR would be even more useless. But it's a losing battle, and NYOB itself is sort of admitting that. https://noyb.eu/en/statement-4-years-gdpr

I'm not sure how much of this is attributable to NOYB, but over the last year or two, years there's been a significant uptick in the number of "Reject All" buttons showing up and I have a hard time believing companies are putting those there out of goodwill.

> GDPR is in theory a good law (although things like mandatory honoring of do-not-track headers should have been obviously included). But it's not being enforced almost at all probably due to regulatory agencies and EU being corrupt AF.

Agree with the missed opportunity of DNT headers being included in the law, but enforcing EU rules is always tricky. At the end of the day, it's 27 different countries, each with conflicting interests. With GDPR in particular, I believe one of the issues is that it's enforced in the country of incorporation, so another country can hold up the enforcement process if their data protection agency is slow, no matter whether due to corruption or incompetence.

Post reply on HN