[kijin]

> A more pragmatic mitigation is to still separate the auth cookie from a dedicated “remember me” cookie and use the latter to re-authenticate the user but impose some restrictions.

What are the benefits of using a separate cookie for the "remember me" feature, provided that you impose the same restrictions (e.g. requiring the password again before accessing sensitive areas of the website) and same security measures like "httponly" & "secure"?

I've been using a single cookie with a randomly generated and periodically replaced session identifier, which expires at the end of the session by default but lasts longer if the user selects "remember me". I'd like to know whether there is a compelling reason to switch to two cookies.

[dasil003]

One significant benefit is being able to enforce a one-time use policy the remember-me cookie. If you only utilize it when the user is not logged in, then you use it to authenticate, set a regular session cookie, and generate a new remember-me cookie. If an old remember-me cookie is ever used that means someone probably sniffed the cookie, and you can invalidate all sessions at that point and even force a password reset if you are particularly paranoid. You can't do this with the regular session cookie because a user might have multiple tabs open. For remember-me the same effect is only a race condition if the user opens two tabs simultaneously.

[kijin]

> 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]

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.

[kijin]

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

[mmcnickle]

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.

[kijin]

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.

[mmcnickle]

The justification is earlier in the article [1].

It slightly lowers the attack cross-section. If you implement the separate login cookie scheme described in the linked article[2] you also get a limited ability to detect hijacked sessions and limit the length of time an attacker has access to the account.

[1] "One argument against long expiration of auth cookies is that they’re effectively keeping the user authenticated and at risk of attacks such as CSRF or clickjacking. Of course the application needs to exhibit other risks in order for an attacker to capitalise on the long lasting cookie but the whole defence in depth argument comes up again."

[2] http://jaspan.com/improved_persistent_login_cookie_best_prac...

[ajanuary]

I think the restrictions are things like restricting by IP, reducing simultaneous use, throttling the rate you can create new sessions.

With a unified token, you have to always trust it for as long as the 'remember me' token is alive. With split tokens, you can do a sanity checks like those mentioned above on every session initialisation.

The value of splitting the tokens into separate cookies seems to be simplicity of implementation. You can rely on the browser to invalidate the session cookie on a browser close, but leave the 'remember me' cookie (as far as you can rely on the browser to do anything).

Every useful restriction I can think of seems brittle, so I guess it's weighing up security against support.

[jbri]

How do you tell if the user's session has expired so you know to ask them to re-authenticate before doing anything sensitive?

[kijin]

AFAIK the re-authentication thing has nothing to do with expiring sessions. The whole point is to ask users to re-authenticate even though their sessions are still alive and well. Enter your password again to change your privacy settings, etc.