by zacharyvoase on 10/23/23, 9:14 PM with 109 comments
by thwarted on 10/24/23, 4:00 AM
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.
by janosdebugs on 10/24/23, 7:30 AM
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.
by zacharyvoase on 10/24/23, 8:14 AM
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.
by oefrha on 10/24/23, 1:56 AM
> 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.
by Beldin on 10/24/23, 5:25 AM
> 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".
by porridgeraisin on 10/24/23, 2:40 AM
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.
by johncolanduoni on 10/24/23, 1:56 AM
by josephcsible on 10/24/23, 3:24 AM
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.
by lesuorac on 10/24/23, 10:22 AM
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...
by FreakLegion on 10/24/23, 1:18 AM
2. https://www.okta.com/blog/2023/06/a-leap-forward-in-token-se...
by bloody-crow on 10/24/23, 3:31 AM
by X-Cubed on 10/24/23, 2:44 AM
by TheGeminon on 10/24/23, 1:12 AM
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.
by patmcc on 10/24/23, 4:57 AM
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.
by gigel82 on 10/24/23, 1:01 AM
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.
by grammers on 10/24/23, 7:37 AM
by dcow on 10/24/23, 7:01 AM
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.
by pyrolistical on 10/24/23, 1:52 AM
Feels like there is a similar algorithm to get that than what is proposed here
by paradite on 10/24/23, 6:28 AM
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.
by codetrotter on 10/24/23, 2:55 AM
Maybe the repo is set to private?
by rmbyrro on 10/24/23, 12:22 PM
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?
by account42 on 10/24/23, 9:43 AM
So it can be stolen from the client or the server. Same applies to this proposal.
by quickthrower2 on 10/24/23, 1:10 AM
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.
by h1fra on 10/24/23, 9:21 AM
If yes, that's cumbersome at best. If no, then it's not really better than cookies.
by c0nfused on 10/24/23, 12:19 PM
by zebomon on 10/24/23, 1:52 AM
By the way, the Github link at the top of the page is 404.
by IYasha on 10/24/23, 1:44 PM
by thayne on 10/24/23, 4:56 PM
by DaiPlusPlus on 10/24/23, 2:47 AM
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.
by username3 on 10/24/23, 1:59 AM