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://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.
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.
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.
:shrug:
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.
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".
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.
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.
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.
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.
Why would you need to put more information into the cookie if it's already unique?
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.
