4 ms·

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

by kijin 13y ago

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

jbri 13y ago
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 13y ago
  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.
ajanuary 13y ago
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.
dasil003 13y ago
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 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 ago
    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 13y ago
      If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.
      - 13y ago
mmcnickle 13y ago
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_practice http://jaspan.com/improved_persistent_login_cookie_best_prac...

by kijin 13y ago

jbri 13y ago

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 13y ago
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.

ajanuary 13y ago

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.

dasil003 13y ago

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 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 ago
  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 13y ago
    If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.
    - 13y ago

mmcnickle 13y ago

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_practice http://jaspan.com/improved_persistent_login_cookie_best_prac...