News for hackers. Stuff that matters.
Re:A practical proposal for migrating to safe long sessions ... by jessaustin on Thursday July 21, 2016 @12:30PM (#12137963)
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.
Re:A practical proposal for migrating to safe long sessions ... by ddalex on Thursday July 21, 2016 @12:57PM (#12138206)
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.

Re:A practical proposal for migrating to safe long sessions ... by mark242 on Thursday July 21, 2016 @01:24PM (#12138445)
"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.

Re:A practical proposal for migrating to safe long sessions ... by ddalex on Thursday July 21, 2016 @05:43PM (#12140320)
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.

Re:A practical proposal for migrating to safe long sessions ... by jessaustin on Thursday July 21, 2016 @06:41PM (#12140553)
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.