Possible Duplicate:
Is it safe to store the password hash in a cookie and use it for “remember-me” login?

I am working on a webapp that uses localStorage alone (http://JonathanHayward.com/calendar-todo) to allow the user to create a server account and have things synced over HTTPS to the server so that the webapp is not chained to a single computer.

I'm running into a bit of a brick wall on one security piece. Storing the plaintext, unencrypted cookie is a red flag, but I'm having trouble making an arrangement that does not look isomorphic to storing an unencrypted cookie. If I store a hash of the password plus a secret, only my server may be able to generate an accepted cookie, but someone who accesses the cookie might as well have the plain text password. The best I've been able to think of is to add the ISO8601 expiration date to the secret and password, and then have the server compare it against hashes computed from today to n-1 days in the future. And at that point I have what looks like a plaintext copy of the password that's only good for so long... better, but not that much better.

What's the best way to make a cookie that is seamless from a user perspective and as useless to a cracker as feasible?


Upon login, create a random value that is stored in your database with a time expiry of your choice (1 day, 1 year, whatever). Pass that random value to the client's browser with the corresponding expiry of your choice (session only, years, etc.)

Now when the client visits a page, they will be transmitting the random cookie to your server which has no connection to their password. If you verify that cookie matches that user in your database, then they are authenticated.

This also gives you (and your users if you implement it) the ability to kill all sessions independently of a password change. It also means that you should implement code to kill all sessions upon a password change.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.