Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You can't do this with the regular session cookie because a user might have multiple tabs open.

Why not? It's considered standard practice to refresh regular session identifiers every X minutes, and this rarely causes race conditions unless your app is AJAX-heavy.

My apps regenerate the session identifier every time it detects that it has been more than 5 minutes since the last regeneration. So if a user who has been away for a few hours returns to the site, his session identifier will be immediately regenerated and the old one will become useless. If race conditions become a serious issue, I can allow the old session identifier to continue to work for the next 30 seconds or so. It also shouldn't be too difficult to add a feature that throws tantrums if someone continues to use the old one much later than that.




If an attacker uses a compromised session id before it is regenerated, the attacker will receive the regenerated session too. They'll have a long-lived session to the victims account.


If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.


If you use the scheme described linked from the article, when the legitimate user logs in again, the attacker will lose access to the session permanently.


Oh, I see. A separate cookie makes it easier for you to check for compromised sessions. I suppose you could also do that with regular session cookies if you keep good track of identifier history, but it'd be a lot more hassle.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: