You don't need to verify the session on the server all the time. Session verification very quickly becomes a bottleneck to app performance, since you're doing a separate database/cache lookup for each rest endpoint request. It's far easier, and provides much better performance, to just cryptographically sign a cookie that says "I'm this user".

This is where the short/long-term cookie comes into play, and is actually a neat idea to take care of the "how do I periodically check that the user hasn't logged out/changed their password/invalidated their sessions/etc" problem that the cryptographically-signed cookie brings up.

Signing something is great but it comes with some possibly unintended consequences.

If you want a stateless cookie, you won't be able to revoke it down the road. Which means if the cookie is long lived, someone who gets their hands on the signed cookie can impersonate a user for a long time.

If you cryptographically sign a cookie and it isn't stateless, you haven't really improved anything because you still have to look into up.

Cryptographically signing a cookie is great, especially for distributed applications, but it does have some properties that might not be desirable.

Still learning about this, but couldn't you: 1. Sign a cookie. 2. Store revocations in a database (remove after session expiry time). 3. Use a distributed bloom filter to avoid db hits for every request. ?

Yes you could, but you still end up with this dependence on a lookup when you store revocations.

Once you do that you lose the stateless benefit of cryptographically signing the object, and at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.

A table of unexpected revocations will be smaller and less write-intensive than a full table of sessions. Should be by a very large margin. And eventual consistency is fine.

So that could be the difference between whatever you're using for storage, and a tiny, fully replicated in-memory structure. Depending on your overall scale, of course.

> at that point you could just store the whole object and give the user a lookup id to the object without the complexity of cryptographically signing anything.

Only if the collision of lookup IDs (accidental or malicious) is effectively impossible. If it's possible to generate a collision, then you've thrown away your security.

This would also effectively give every server the ability to issue auth tokens (and mutate them in the DB), which is not a great choice if you care about security. But if you're handing out unsigned lookup IDs, you probably don't.

What purpose could signing a lookup ID possibly serve? Are you worried that someone might correctly guess the 128 bytes of the identifier and hoping they won't guess the 32 of the signature?

You're using 128 byte identifiers? Why?

And actually, yes, if I were using 128 byte identifiers for some reason, I would still be concerned about malicious parties being able to cause collisions. Securely generating random numbers does not seem easier than authenticating.

Just to chime in since I'm the OP of this subcomment.

Generating 128 byte identifiers is ridiculously overkill. I can safely say if you generate 128 byte identifiers securely, the earth will cease to exist before a collision is found.

You would be safe generating cryptographically secure 128 bit identifiers and looking them up. It is trivial to generate IDs that will not collide.

My point is that, if someone is going to guess the N bit identifier, they can also easily guess the signature.

Depends entirely on how well you generate your IDs. Yes, if you generate cryptographically strong IDs of sufficient length, then you don't need to sign.

Signing avoids the need to generate secure IDs, though, and can also avoid hitting to the DB for expired tokens. (Load from expired tokens is probably not a major concern, though.)

That sounds like a time-space trade-off to me. I'd think cryptographic signature verification would be more expensive computationally than a cache lookup and compare, but not require much space. Also, and maybe this is the key part, it would be more distributable since you don't need shared state.

Cryptographic signature verification can be expensive, but the previous commenter (and, to be fair, pretty much the whole software industry) is abusing the term "signature". Really, what we're talking about is cryptographically authenticated messages. Verifying an authenticator is extremely fast.

Can you clarify what the difference is here? How do you verify an authenticator without verifying a signature?

Pedantically, a "signature" is the product of a public key signature algorithm. It's what you use when you have multiple and/or anonymous verifiers.

An authenticator is the product of an authentication algorithm, which can be as simple as a keyed SHA-3 hash (a hash over the data to be authenticated and a key known only to the verifier).

Session tokens virtually never use signatures. The only party that needs to verify them is the serverside of the application that generates them; they're opaque to clients.

So you're assuming the session tokens are authenticated with a shared key. I guess that makes sense from a perf standpoint. It seems iffy from an isolation standpoint, though. I wouldn't think you would want every server holding effectively global auth keys.

Edit: I guess this is actually a good case for the 2CH described here. The long-session cookie could be cryptographically signed, while the short-session cookie could be authenticated with a shared key that gets rotated frequently so that a leak of the key cannot cause a long-term compromise.

I don't know what you mean by "isolation", but virtually every mainstream system that stores secrets in tokens uses MAC constructions, not signatures. Signatures are much more complicated and dangerous.

Don't ever use public-key crypto unless you absolutely need it.

Isolation meaning that every web server cannot issue authenticated cookies for arbitrary users. I'm clearly not a security expert but that seems to greatly increase the damage scale of a single web server breach.

Also, how would you store a secret in a token without encryption? Or was that just a misstatement?

In practice, you do one of three things:

1. You encrypt and then authenticate data, such as user profile information, so that clients can neither read nor alter it. This doesn't involve public-key encryption.

2. You authenticate data, but don't encrypt it, because it isn't secret but must not be changed; this is what you'd do if the only semantic value being passed in your token as UUID, for instance.

3. You do neither of these things, and instead generate cryptographically random tokens of sufficient length that they can't be guessed, and then use those tokens as database lookup keys.

All three of these things are lightning fast on any decent processor, including the one on your phone.

You are very likely to cost yourself more security than you gain by trying to do anything more complicated than one of these three things. Again: don't ever use public-key crypto unless you really need it.

Thanks. Sounds like I need to do some more research on this. This isn't how I thought this was generally implemented by the big players, but I've not worked closely on auth either.

I guess for 2 and 3, you handle revocation by just deleting the relevant row or flagging a "revoked" column. For 1, add a unique id that you can add to a revocation list? Are there better/more typical ways to do this?

Revocation is a problem for encrypted tokens; it's a downside to the approach. The common solutions aren't particularly elegant.

A fourth option would be just like option 3, except you only use part of the DB token in the lookup and compare the remainder in constant-time if and only if the record exists (if you're worried about the database lookup leaking a valid authentication token).

Agreed that public key crypto isn't really appropriate here.

He means that the auth key has to be shared between N servers, ie you can't have a scenario where a server can verify all the others' signatures but can only issue its own.

This might help: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

Yes; and CPU is cheap as hell. Round trips to a cache are expensive.

That depends on where your cache is.

If your cache is on a separate box and you have to make a network round trip, yeah it is expensive.

But if your cache is in-process, the access is cheap.

Also, CPU tasks like authenticating a message are cheap to scale horizontally. A cache is a centralized bottleneck.

You can re-verify on the backend however often you like.

Make the signed cookie include user-id and date (and maybe a session id). Accept it without backend-check while it's less than X minutes old. Buf if it's older than that, check the backend to see if the user has invalidated sessions since it was generated. In the typical all-good case, generate a new signed cookie and put it in the response. No need for service workers or anything.

A web company I worked for a couple years ago implemented something almost exactly like this while I was there.

A simpler solution is to simply keep the connection open until the session is complete. That way you can use the long-lived session token (in the cookie) each time the user visits your site/app and then just keep a WebSocket open while the user is connected.

This has many advantages beyond the short/love-lived cookie stuff.

Actually a good reason might be scalability. Authenticating every single request creates a big load on your authentication service. That's a lot of RPC's, particularly if you're using single sign-on and those RPC's are coming from every web app you run.

The point is that verifying on the server can be a pain. TFA's proposal avoids doing so, much of the time. One could imagine rolling out any number of parallel "service workers" to perform this task without needing to complicate the server with concerns about a single user's requests hitting multiple servers that therefore need to stay on the same page with respect to token revocation.

The session has to be fetched from cache/hot memory on every request, right? Authenticating the session per request may be expensive, but actually clearing the session cache so the request can't even get the session data - that's much better.

So you don't need to invalidate the auth tokens. You just need to be able to delete a session from the cache to do revocation on long sessions. And this works with just backend changes, no client hockey-pokey needed.

"The session has to be fetched from cache/hot memory on every request, right?"

Nope. Let's say you have a rest endpoint that accepts a Pokemon id to add to your collection. If you cryptographically sign a cookie that says "I am this user id" you can assume the request to add the Pokemon to your collection is valid. There's other business logic to perform, sure, but "I am this user" is taken care of for you.

What Google is proposing is the ability to save a long-term cookie that says "I am this user" and a short-term cookie that says "I'm signed in". The requests periodically say "am I still signed in/am I still this user" and the server can periodically (eg not every request) look that up in cache/database.

My point is that at some point, you have the control on the server. Of course, you can encrypt the session information in the cookie, and decrypt it on the server end, verify signature, and certify that the user is who they say it is.

This just moves the problem a bit - if you want to log out a user, you can just erase the cookie key from the server side; the cookie will be just random noise at that point.

This approach, of course, assumes that your keys are user specific, possibly generated from the password.

You're right, if every authenticated cookie must also be validated against the DB, there is no point to using authenticated cookies. TFA describes short-lived authenticated cookies, which need not be validated against a DB, used in conjunction with longer-lived DB sessions, which are only validated against the DB when the short-term cookie has expired. Those DB sessions end on logout or reset or whatever.

Would there ever be a reason to have the cookie expire at all?

If the password is changed, you can invalidate the session, but the cookie remains?