Show HN: WebSession, a Secure Replacement for Cookies
websession.dev
websession.dev
No, the correct way to do this is to use the cookie to store an opaque session identifier generated at each login, then expire the session data on the server sometime after its last touch. This solves both forcing expiration and the copying/hijacking of cookie values from long-saved browser state.
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.)
https://stackoverflow.com/questions/15959244/
Bottom line, you can simply listen to mouse move events and invalidate the current session on user inactivity.
https://github.com/googleapis/nodejs-firestore-session/issue...
I agree that WebSession would benefit from a time since last touched expiration, although I'll point out that a time-based approach doesn't handle the "when device is locked" requirement.
I noticed it because I delete site cookies often, and paste them in from a file whenever I want to comment. Occasionally click "logout" without thinking. Got creeped out by that year-in-review thing they do once.
This has nothing to do with cookies, the banner is required if the site is processing data that is not just technically necessary. In this case the site needs to ask the user for consent or at least inform them of processing due to legitimate interests.
https://noyb.eu/en/noyb-aims-end-cookie-banner-terror-and-is...
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
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.
Having a lot of money, lobbyists and lawyers makes you immune to the law.
NOYB’s intervention has lead to fines and I’ve been seeing way more banners have a “Reject All” at the top level. I remember noticing that at the same time NOYB posted about it. Unfortunately I don’t remember any useful keyword to search their website and post the source.
Though I’m not disagreeing with you. I have no doubt the dark patterns will continue and these companies will be as vampiric as they can get away with.
My strategy is to use that as a useful signal: the more a company or website bends over backwards to try to get me to accept data collection, the more I know I can’t trust them and will simply leave.
A lot of the nags have indeed gotten less illegal lately. Although I have very little faith in that even clicking Reject All really prevents tracking and selling me out. There are still those "legitimate interests" etc loopholes. And probably no regulator actually checks that the Reject is honored at all. Nowadays I don't even care. Used to go private mode for those but don't bother anymore. Hopefully at least my aggressive ad blocking makes spying on me mostly worthless on them.
Implementation of the GDPR consent was broken from the getgo (likely due to corruption). The spirit of the law is clearly that people shouldn't be tracked if they don't want it. Vast majority don't want to be tracked but vast majority are tracked.
If EU would have actually wanted this to work it would have been something like DNT. Also the promised megafines have not (and will not be) materialized and the (widespread and blantant) violations are at best just cost of doing business.
But making an actually effective implementation would have closed many revolving doors and fancy dinners.
Sorry for being so negative on this but I think entertaining hopes for such a fundamentally broken system may prevent less broken ones from arising.
https://www.enforcementtracker.com/ (going through the cases also shows that the DPAs are mostly fiddling with small fish who don't have the corruption power and/or lawyer army)
> (…)
> Also the promised megafines have not (and will not be) materialized
https://noyb.eu/en/spotify-fined-eu-5-million-gdpr-violation
https://noyb.eu/en/noyb-win-first-major-fine-eu-1-million-us...
Grindr did get almost 3%, so that would be at the megafines level. Wonder how much they gained by selling the data though.
In comparison, I'd get easily fined over 3% of my yearly wage for shoplifting here in Finland. And of course would lose whatever I lifted. For Grindr-level privacy crimes I'd probably get a prison sentence. If you want to break the law, better make it for shareholder profit.
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.
My take is that the corruption is not only a national matter, like europhiliacs and the EU's huge PR-propaganda machinery like to explain it. EU was set up as an antidemocratic organization for business interests and seems to remain so. The endless lobbying billions work.
They filled over 500 complaints for that alone.
https://noyb.eu/en/noyb-aims-end-cookie-banner-terror-and-is...
They sent draft complaints to the companies. Not sure how many they sent to authorities. But nevertheless it may have had an effect.
He had to explain that they re-engineered the page a while back to not collect any data besides what the person puts into the form (the page explains that collection, but inline) so they wouldn't need one. Don't know if it was an aesthetic choice or if they AB tested it.
:shrug:
Often if it’s a custom cookie banner it will only have an “accept” button (no way to reject!) and usually with vague language like “ok”
Even where they do have the right language and a way to reject cookies, sometimes the site sets cookies ahead of the user actually accepting them.
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 session, so you could wait to allocate storage for them until the client actually tries to set up a WebSession, and use a Bloom filter to save on storage at the risk of some false positives for nonce reuse (could be risky if you’re relying on that as tamper evidence, but you could tune your filters accordingly).
* The stuff about the ergonomics of cookies and banners and auto-log-out as they currently are is mostly incidental. I’m just trying to paint a picture of how tighter integration of the notion of a ‘session’ into the browser itself could improve the UX we currently have today.
* Many people have pointed out that this is not stateless. Indeed! This is supposed to be a more secure way of establishing a stateful connection over a stateless protocol, for which there is already a demand which we’re meeting with the least secure possible method (bearer tokens sent in plaintext over the channel). Issues with scalability need to be addressed on the implementation side, but I believe the protocol is still sound and not inherently unscalable (no more than TLS in its current form).
I am going to look for opportunities to fold these points into the document itself, and maybe rearrange some of it so that these points get covered earlier and more clearly.
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.
Just send a signed UTC timestamp instead of a nonce. Make it valid for like 5–15 seconds to ensure it doesn't break if clocks are out of sync slightly – it will still be better than cookies that live practically forever.
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 method so legislation can force disallowing all cookies and tracking, or blanket ignoring them client side.
Then nonce storage, if you do it, can be limited to window when it is valid.
> 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.
>> 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.
I.e. it was assumed there was a sequence number, and I refuted that it disallows concurrent requests.
In general, I agree a signed timestamp is fine.
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.
> 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".
Asking for a friend: Is the the European Parliament also a part of the industry colluding to undermine legislation?
What they should have done is raise the "Do Not Track" flag to legal status. If the flag is enabled it must be obeyed without any further questions to the end-users. Making it mandatory would have solved the problem with this flag which was that everyone simply ignored it and it only added an extra bit of entropy for fingerprinting.
If this flag had become mandatory, the browsers that have removed it would have brought it back immediately because it actually would have become functional. Also, the onus would have been on the advertisers to stop friction for those who don't mind to be tracked. Instead of tricking people with cookiewalls the focus would have been on making the "tracked" experience as frictionless as the flag itself is.
But I guess the industry lobbied very heavily for this flag not to become mandatory because it would have instantly cut their tracking to near-zero and therefore remove the raison d'etre of many of these adtech businesses. It would have shocked the industry more than Apple's ID thing did to facebook. No big deal though IMO because this industry is undesirable and it would have triggered some real innovation in context-driven ads that are not privacy invasive.
It would have been the only good option though for the citizens. What the EU has done has only backfired on itself with everyone including the lobbyists blaming them for the cookiewall mess.
Except you need to completely delete all data for users who close their account. Need to have a data protection officer, and need to have a way to give users all the data you have from them upon request. All of which can be a significant burden for small companies, or non-commercial websites.
Well, you're a good example about people misunderstanding GDPR :)
If you're a small company and processing data isn't a core part of your business and whatever the business does doesn't create risks for your users, there are parts of GDPR you don't have to care about, for example you don't need to have a DPO in that case.
GDPR is meant to protect users from businesses that are harvesting users data, in order to gain a bit of privacy back. It's not for your tiny SaaS that only requires a email to use and you collect no analytics about users.
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 extensions like uMatrix.
Why would you need to put more information into the cookie if it's already unique?
About the backwards compatibility - the whole idea suggested in the article is that the user can block all cookies and use WebSession. That isn't backwards compatible with PHPSESSID either.
Ah, here's the evil part. If I don't want my browser to log me out of my bank's website when I lock my screen, my bank shouldn't be able to make it do so anyway.
Really disappointed that Mutual TLS didn't replace Cookies. Could've had Zero-Sign-On capabilities a long time ago with mTLS.
https://www.cloudflare.com/learning/access-management/what-i...
2. https://www.okta.com/blog/2023/06/a-leap-forward-in-token-se...
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.
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.
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.
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.
It looks pretty reasonable to me (except possibly the nonce-management bit). I can't be bothered to try and pick it apart, and anyway I'm no expert.
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.
Feels like there is a similar algorithm to get that than what is proposed here
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.
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.
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.
Maybe the repo is set to private?
We'll just make (different) silly mistakes with the new tech.
Instead of reinventing the wheel, why don't we just gradually improve the defaults for cookies in browsers and educate developers on using the tech we already have with security consciousness?
So it can be stolen from the client or the server. Same applies to this proposal.
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.
If yes, that's cumbersome at best. If no, then it's not really better than cookies.
By the way, the Github link at the top of the page is 404.
I see some problems:
1) This is a stateful protocol: Bearer-tokens are popular despite their insecurity because they allow remote-services to be entirely stateless (and thus, scalable), but this approach requires the remote-service to maintain a database of current private sesion ids ("Looking up the corresponding Spriv for the session;") and storing the nonce of every request made ("while also checking to make sure that nonce has not been used before."). This will not scale (and could even be a way to DDoS a server by hammering it with requests from distinct sessions).
2) The requirement of a handshake: which means the first HTTP request a browser makes can't be pre-authenticated, which makes for a suboptimal user-experience.
3) Good luck getting browser-vendors to all buy-in to this; I'm sure Mozilla will be happy to accept a PR, but the other players (Google, Microsoft, and Apple) will all have their reasons to drag their feet on this, and that's assuming it's even in their interests to support this (e.g. look at how Google tried to kill Apple's Storage Access API).
4) The hard requirement for a browser-based UI restricts the kinds of session activities you can support, e.g. consider how larger-scale web-applications don't have simple, single-user sessions, but will support things like impersonation, delegation, multi-tenancy and tenant partitions - this can't be reconciled with how browser-vendors will only want to display (at most) a simple yes/no prompt or a list of known sessions.
When it comes to new browser-based security protocols, it's a triangle problem: Replay protection, Statelessness, No handshake requirement: pick any 2.
----
Request-signing can work, obviously we can't rely on whole-request signatures (because the body-length is unbounded and can be streaming); but using a time-based nonce with a remote-service-provided preshared key (which can be derived from the existing underlying TLS session without needing a HTTP handshake). ...but what value does this add when cookies+TLS already work fine for this purpose? Thus, this is why nothing changes in this area.
I'd very much rather see a "Cookies 2.0" ("WebCookies" to use the current nomenclature) that provides a way for a declared JS (just like with ServiceWorkers today) to run with privileged access to the user's cookie store (thus side-stepping XSS/script-injection problems; the "trusted JS" could be declared via a HTTP header) as well as (yet another) cookie flag, but this time to designate cookie-expiration-due-to-local-user-inactivity. Oh, and a proper DOM API for cookies like we have with localStorage, and not the horrible stringly-typed `document.cookies` property. I don't understand why no-one has seen fit to add simple `add(key,value)` and `get(key)` functions to it. Argh.