Show HN: WebSession, a Secure Replacement for Cookies

How does this compare to Phoenix LiveView websocket sessions?

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.

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.

TL;DR: A web-browser-based, non-JS-exposed, request authentication scheme using signed requests.

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.

> 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.

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.

It's a user-agent directive, so should be controllable in your browser.