Hacker News Reader

Comment by geku | Hacker News Reader

How about simply storing a logout timestamp in the database when a user logs out? Whenever a user logs in again the timestamp field is cleared and as long as that timestamp field is empty the session cookie is accepted, otherwise ignored and the user is forced to log in again.

Basically we still get benefits from storing the session data client side (much less db access) and only store minimal data on the server side.

View on HN

This could be problematic if the same user is logged in from multiple machines. Logging out from one client will invalidate all of the other sessions. For some web applications this would be seen as a bad experience to the user.

Another issue is old sessions may be deactivated once the user logs out, but all those old sessions suddenly become valid again when the user logs in again, since the time stamp field is now present. It doesn't prevent the issue the author is highlighting (that sessions can last forever).

Would that not mean that the cookie could still be re-used by a malicious user who had intercepted it, as long as the real user had subsequently logged in again?

I guess it reduces the attack surface (the genuine user must be logged in at the same time as the attacker) but doesn't completely solve the problem.

Yes, I think you are right. Additionally the cookie could have a creation timestamp and in the db the last login time is stored. So when the cookie timestamp is older than the last login the cookie is actually outdated and ignored. But again maybe it's simpler to just use serverside session storage ...

This seems like a really elegant solution, I've not given it much thought, so it could turn out to be flawed, but definitely worth pursuing.

Reply on news.ycombinator.com