views:

182

answers:

4

I want user's to be able to select a "remember me" box on my website so they need not log in each time they come. So, I need to store a unique ID in a cookie to identify them. Is it safe to hash their password with sha512 and a long salt in PHP and store that value in the cookie? If the cookie was stolen, would their password be at risk? Obviously it must be connected to their password somehow, otherwise if the cookie value was guessed or stolen, the user would not be able to stop someone else logging in.

Also, is it advisable to use a GUID at all as the unique identifier?

Thanks, Ben

+2  A: 

There's a low risk with a good algorithm and large salt, but why take any unnecessary risk?

If you just need to identify the user, then store something that can uniquely identify the user, like a guid along with some other stored verification code (not their password, some random long string). I wouldn't use a guid alone as it would not be a safe method of authentication.

Sam
It is advisable to delete or modify this "random long string" when/if the password is changed, lest the user (or someone with the said cookie) were to present such a cookie some time after the password was changed (or the user de-selected the remember me, or...)
mjv
The "random long string" should expire much more often than when the password changes, ideally at every login.
Matthew Flaschen
The string points to a user. It has nothing to do with authentication. You can delete it whenever you want to expire cached credentials, which is not really related to changing the password.
Sam
@Sam agreed; _technically_ the cached _identification_ is unrelated to the current value of the password. However, a bit like when someone changes the lock on their home's door, he/she expects that any other mean of entry (like a hidden key under the map, even if such analogy if flawed) will be so voided. Such expectation carries into the virtual world, and that's why it is probably a good practice to void the cached id.
mjv
@sam, -1 leaking the password hash is ALWAYS a vulnerability.
Rook
Thanks! Wouldn't re-creating the random number on every login log a user out of one computer if they logged in on another?So a safe method of authentication, seems to be to generate a random set of characters, say 256 bits, and append that to their userid and check that. When they log out or change their password, it clears or creates a new random string.
Ben
+6  A: 

Remember, the hash of the password is effectively the same as their password. Somebody who stole the hash would have the same access to the user's account as if they had stolen their password. Therefore it is not advisable to store a hash of the user's password in a cookie unless there was some other information not stored with the cookie that is used to authenticate (i.e. 2-factor authentication).

Gabe
+1 exactly, otherwise whats the point in even hashing the password in the first place? Its designed to delay the attacker!
Rook
I wonder why somebody voted down on this answer.
Gabe
A: 

It wouldn't hurt to have some kind of "password" in the cookie along with a user id (to prevent users from changing the uid to that of another user), just don't make the "password" the same as the actual user's password.

And just because it's a hash doesn't necessarily mean it's one-way (well, by definition it does, but there are utilities to generate MD5 plaintexts and I would guess it's only a matter of time before it happens to others). I would hash some kind of secondary password.

advs89
+1  A: 

Here is an excellent article on this very topic. Many of the answers to your question are hitting on techniques outlined in it.

Chris