Show HN: WebSession, a Secure Replacement for Cookies

<i>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 should be able to request that the browser clear a session in the case of device lock, the user navigating away, etc.</i><p>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&#x2F;hijacking of cookie values from long-saved browser state.

&gt; Because WebSession is dedicated to session maintenance and nothing else, a client could theoretically reject all cookies on any supporting site, ideally skipping the jarring cookie banner experience.<p>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.

Hi! Author of this proposal here.<p>I’m loving all the feedback and wanted to address some things:<p>* 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).<p>* 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.<p>* 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).<p>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 only thing in this protocol that prevents the reuse of Authorization header is keeping track of nonce:<p>&gt; 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.<p>That&#x27;s one extra db row &#x2F; kv pair for every single request, including read requests, for very little benefit.<p>Request signatures incorporating timestamp and optionally path&#x2F;payload are stronger, can be statelessly validated, and are already in use today on certain sites.

From the article:<p>&gt; <i>As a result of increasingly strict privacy laws across the world, users are now beset with cookie banners across the Web</i><p>In the words of a law prof from the Radboud University, more accurate is to say &quot;as a result of an entire industry colluding to undermine legislation&quot;.

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.<p>Everything else in the proposal isn&#x27;t really required.<p>Considering this, simply choosing a standard name for session cookies suffices.<p>Browsers can give an option to the user to rejects all cookies that don&#x27;t have the name &quot;WebSession&quot;. This is already achievable using extensions like uMatrix.

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 or errant logging really a big source of compromised bearer tokens?

&gt; 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, <i>especially</i> because security requires that such cookies not be visible to JavaScript. A native session management solution should be able to request that the browser clear a session in the case of device lock, the user navigating away, etc.<p>Ah, here&#x27;s the evil part. If I don&#x27;t want my browser to log me out of my bank&#x27;s website when I lock my screen, my bank shouldn&#x27;t be able to make it do so anyway.

Isn&#x27;t this Mutual TLS with extra steps?<p>Really disappointed that Mutual TLS didn&#x27;t replace Cookies. Could&#x27;ve had Zero-Sign-On capabilities a long time ago with mTLS.<p><a href="https:&#x2F;&#x2F;www.cloudflare.com&#x2F;learning&#x2F;access-management&#x2F;what-is-mutual-tls&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.cloudflare.com&#x2F;learning&#x2F;access-management&#x2F;what-i...</a>

DPoP[1] is on its way and already starting to see adoption by identity providers like Okta[2] (oh, the comedy). It&#x27;s unfortunately specific to OAuth, so narrower in terms of application, but will cover how most web apps work today.<p>1. <a href="https:&#x2F;&#x2F;oauth.net&#x2F;2&#x2F;dpop&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;oauth.net&#x2F;2&#x2F;dpop&#x2F;</a><p>2. <a href="https:&#x2F;&#x2F;www.okta.com&#x2F;blog&#x2F;2023&#x2F;06&#x2F;a-leap-forward-in-token-security-okta-adds-support-for-dpop&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.okta.com&#x2F;blog&#x2F;2023&#x2F;06&#x2F;a-leap-forward-in-token-se...</a>

I feel like nonce-tracking on the server side makes it a non-viable solution for a lot if not most of applications. A nonce needs to be stored&#x2F;validated on every request, even a GET one. Seems like a recipe for DDoS.

I don&#x27;t get why WebSession proposes to use authentication headers like WWW-Authenticate, when it calls out at the start that it&#x27;s not a replacement for authentication protocols. If that&#x27;s the case, surely it should just be using it&#x27;s own headers to avoid confusion.

This seems like a great way to pull out session identity from cookies and sidestep a lot of the baggage there.<p>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.

&gt;&gt;&gt;If someone steals this cookie, they can impersonate you.<p>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?<p>Cookies aren&#x27;t perfect, for sure, but I don&#x27;t think this solves it.

Not going to comment on the technical merits of this proposal because it&#x27;s not my area of expertise but as a user I look at any proposal in this space with extreme caution (because most of the time &quot;the man&quot; really is out to &quot;get you&quot; - see &quot;Web Environment Integrity&quot;).<p>I&#x27;m a big fan of Firefox&#x27;s Total Cookie Protection and make extensive use of the &quot;Temporary Containers&quot; extension, so I will likely disable this feature as well if it becomes standard because it eventually boils down to making tracking easier.

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

Few things commenters are missing:<p>1. If you want the protocol to be “stateless” (once the session is established, that is), use a fixed, or allow any, nonce.<p>1.5: The proposed nonce tracking scheme <i>is</i> 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.<p>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.<p>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.

Seems complicated. Seems like what is desired here is some sort of shared secret. Then use it to generate a sequence of session ids.<p>Feels like there is a similar algorithm to get that than what is proposed here

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.<p>This protocol seems to also depend on JS to do client side cryto logic and adding HTTP headers. Unless by browser&#x2F;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.<p>I wonder how this compares to using sessionStorage.

It links a github repo, but that repo gives 404<p>Maybe the repo is set to private?

New tech will not magically make developers security conscious.<p>We&#x27;ll just make (different) silly mistakes with the new tech.<p>Instead of reinventing the wheel, why don&#x27;t we just gradually improve the defaults for cookies in browsers and educate developers on using the tech we already have with security consciousness?

&gt; Even with all of these, a compromised client, an unsecured application log, or an eavesdropper on the connection after TLS termination could result in a cookie being stolen.<p>So it can be stolen from the client or the server. Same applies to this proposal.

Seems like a good proposal to me. Maybe there are privacy&#x2F;security holes?<p>Is it sort of like a &quot;rich mans&quot; CSRF token, but you don&#x27;t need to put it in the form, and it works on all requests GET, POST, ..., and is cryptographically secure etc.

I&#x27;m not sure I got everything in this paper, does that mean users have to sign-in again each time to go to a website?<p>If yes, that&#x27;s cumbersome at best. If no, then it&#x27;s not really better than cookies.

What is the advantage here compared to cert auth which is already supported in most browsers? Aside from ease of installing a client cert.

Great overview of cookie&#x27;s shortcomings, and thank you very much for the solution.<p>By the way, the Github link at the top of the page is 404.

It would probably be okay as long as I can view, edit and manage them in every way I like.

What about use cases where JavaScript needs to be able to read or write a cookie?

TL;DR: A web-browser-based, non-JS-exposed, request authentication scheme using signed requests.<p>I see some problems:<p>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 (&quot;Looking up the corresponding Spriv for the session;&quot;) <i>and</i> storing the nonce of every request made (&quot;while also checking to make sure that nonce has not been used before.&quot;). This will not scale (and could even be a way to DDoS a server by hammering it with requests from distinct sessions).<p>2) The requirement of a handshake: which means the first HTTP request a browser makes can&#x27;t be pre-authenticated, which makes for a suboptimal user-experience.<p>3) Good luck getting browser-vendors to all buy-in to this; I&#x27;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&#x27;s assuming it&#x27;s even in their interests to support this (e.g. look at how Google tried to kill Apple&#x27;s Storage Access API).<p>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&#x27;t have simple, single-user sessions, but will support things like impersonation, delegation, multi-tenancy and tenant partitions - this can&#x27;t be reconciled with how browser-vendors will only want to display (at most) a simple yes&#x2F;no prompt or a list of known sessions.<p>When it comes to new browser-based security protocols, it&#x27;s a triangle problem: Replay protection, Statelessness, No handshake requirement: pick any 2.<p>----<p>Request-signing can work, obviously we can&#x27;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.<p>I&#x27;d very much rather see a &quot;Cookies 2.0&quot; (&quot;WebCookies&quot; 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&#x27;s cookie store (thus side-stepping XSS&#x2F;script-injection problems; the &quot;trusted JS&quot; 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 <i>proper</i> DOM API for cookies like we have with localStorage, and not the horrible stringly-typed `document.cookies` property. I don&#x27;t understand why no-one has seen fit to add simple `add(key,value)` and `get(key)` functions to it. Argh.

How does this compare to Phoenix LiveView websocket sessions?