18

I want to store an encrypted string of the password hash in a cookie and use the hash to lookup the user and log them in (if they want to be remembered).

Is this safe? The password is one-way hashed with SHA-512, 1024 iterations, using a timestamp for salt.

I imagine this would be unique because of the time-stamp salt.

Improve this question
2
  • 1
    use server sessions. If you ever have to ask if it's safe, it isn't.
    – zzzzBov
    Dec 5, 2011 at 19:23
  • Note: Make sure your cookies are "secure" (mitigates MITM attacks) and "httponly" (mitigates XSS attacks).
    – Brian
    Oct 2, 2012 at 21:30

2 Answers 2

Reset to default
22

No, this is not safe

You should generate a long random number and store it in a cookie. This random number is essentially just another password for this user. So, on the serverside, you only store a properly salted hash of this random number.

You should only give out each number once and it should only be valid for 1 login. So allow for more than one of those hashes for each user. Upon successfully logging in, generate a new random number, give the new number in the cookie you give it to your user and store the (salted) hash of this number on the server side.

(On a side note, MD5 is not deemed good enough anymore for password hashing and a salt should be random; a timestamp is not random enough. Search for password storage here for more information on that.)

Improve this answer
11
  • Thanks for the info. I meant to say I use SHA-512, not MD5 for password encryption.
    – Mohamad
    Dec 5, 2011 at 14:41
  • 4
    Ideally go for BCrypt Hash. Read: security.stackexchange.com/q/4789/2113
    – Jacco
    Dec 5, 2011 at 14:43
  • and also: security.stackexchange.com/q/4574/2113, security.stackexchange.com/q/211/2113 or maybe use the search box in the upper right corner.
    – Jacco
    Dec 5, 2011 at 14:45
  • 2
    A salt does not have to be random, it does have to be unique to every user!
    – ewanm89
    Dec 5, 2011 at 14:56
  • I don't understand something, perhaps this is another question in itself. Why does it matter if the userId is know? There are many sites where you can view people's ids by navigating to their profile page: *.com/users/123 -- doesn't that depend on the security of the application itself? Why do we need to encrypt a userId/hash when the id is readily available by visiting someone's profile?
    – Mohamad
    Dec 5, 2011 at 15:07
9

No. To verify this, you would have to store the hashed value on your server to compare against, otherwise you wouldn't be able to invalidate login sessions; or even worse you would need to store the plaintext password and timestamp used in order to regenerate the value. If you're going to be storing a value between two machines to compare, that value should be random.

While your method increases the work that would need to be done to compromise the system, it creates more complex work than storing a random value and it does expose a brute-forcing weakness -- especially where many browsers log the creation time of a cookie, thus exposing timestamps you were likely to use.

Improve this answer
2
  • No it doesn't all I need is a cookie with the hash in. Easy to generate and even easier to sniff off the wire (unless over SSL).
    – ewanm89
    Dec 5, 2011 at 14:55
  • @ewanm89 Please expand on what you're trying to say. It sounds like you're describing a Firesheep-like attack which any session data can be vulnerable to.
    – Jeff Ferland ♦
    Dec 5, 2011 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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