How to build (and how not to build) a secure “remember me” feature
1–10 of 65 posts
Re: How to build (and how not to build) a secure “remember me” feature
#2> 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.
Re: How to build (and how not to build) a secure “remember me” feature
#3> 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…
How do you tell if the user's session has expired so you know to ask them to re-authenticate before doing anything sensitive?
Re: How to build (and how not to build) a secure “remember me” feature
#4> 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…
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.
Re: How to build (and how not to build) a secure “remember me” feature
#5How does the "reference implementation" of ASP.NET actually work? Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? It seems that the article doesn't say.
Re: How to build (and how not to build) a secure “remember me” feature
#6I tend to like doing: sha256(sha256($password) . $ip)
This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.
Re: How to build (and how not to build) a secure “remember me” feature
#7I tend to like doing: sha256(sha256($password) . $ip) This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.
What if the user gets their session hijacked when they're on a static or long-term dynamic IP? If the user were to relogin, their session ID would be the same. I think it would be beneficial to at least store a salt associated with their session and regenerate the salt when authenticating.
sha256($password . $ip . $random_salt)
You could also regenerate the salt periodically.
Re: How to build (and how not to build) a secure “remember me” feature
#8Good article, but one thing is explained in a weird way:
Don't bother with cookie expiration. That's the wrong approach, because the cookie is controlled by the user. Always do a server-side check whether or not the auth token in the cookie is allowed to continue the session.
So you could simply set the expiration date for a cookie until 2030 but make sure that the auth token from that cookie cannot be used after $EXPIRATION_TIMESTAMP on the server.
You could also follow a layered approach:
If the user logs in every few days, re-authenticate him using the auth token from the cookie. But if the user was seen more than $MAX_INACTIVE_DAYS ago, do not re-authenticate and terminate all sessions, even if the "remember me" function is set to half a year or so.
Re: How to build (and how not to build) a secure “remember me” feature
#9Regarding how long to keep the "remember me" cookie for, this is one of the overlooked reasons why native apps are eating the web's breakfast. When was the last time you have to re-authenticate on a native mobile app?
Maybe it happens on some finance/banking apps, but I don't recall seeing it on apps like Facebook or Kindle for example.
Web developers could, for example, add longer times if the user agent is mobile.
And Troy is spot on about the middle ground of "logged-in-ness". Developers are finally realising what Amazon knew all along, that it's not binary. You can keep the user partially logged in, while requiring authentication to perform sensitive tasks.
Re: How to build (and how not to build) a secure “remember me” feature
#10I tend to like doing: sha256(sha256($password) . $ip) This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.
> since I already store sha256
Storing SHA-256 of passwords is a bad idea. You should use either scrypt, bcrypt, or at the very least PBDKF2 (with a large number of rounds).
For a signed token round tripped to the client you should use an HMAC[1].
[1]: http://en.m.wikipedia.org/wiki/Hash-based_message_authentica...