3 ms·
> 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
by kijin 13y ago
> 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.
- mmcnickle 13y agoIf 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.
- kijin 13y agoIf the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.
- mmcnickle 13y agoIf 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.
- kijin 13y agoOh, 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.