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.

Mohamad
  • 477
  • 1
  • 6
  • 11

2 Answers2

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

Jacco
  • 7,672
  • 5
  • 33
  • 54
  • Thanks for the info. I meant to say I use SHA-512, not MD5 for password encryption. – Mohamad Dec 05 '11 at 14:41
  • 4
    Ideally go for BCrypt Hash. Read: http://security.stackexchange.com/q/4789/2113 – Jacco Dec 05 '11 at 14:43
  • and also: http://security.stackexchange.com/q/4574/2113, http://security.stackexchange.com/q/211/2113 or maybe use the search box in the upper right corner. – Jacco Dec 05 '11 at 14:45
  • 2
    A salt does not have to be random, it does have to be unique to every user! – ewanm89 Dec 05 '11 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 05 '11 at 15:07
  • @ewanm89, I wrote a long answer about that on stackoverflow http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco Dec 05 '11 at 15:16
  • @Jacco, yeah, but most of your answer is about lack of salt length really, when you are moaning about using UID. Random works accept it's perfectly valid for a random number generator to spit out the same string again, what one needs is a long enough string that is unique to every user. Now if one was saying using public email addresses as the username and public key in your database then that would be okay to use. even the shortest email address must 6 characters long. – ewanm89 Dec 08 '11 at 20:49
  • @ewanm89, no, this would not be ok. The salt should be unique world wide. If you use an email adress instead of a (random) salt, and the user reuses the password, you can attack two or more systems for the cost of one == bad strategy. – Jacco Dec 18 '11 at 18:17
  • only if both systems prepend or both postpend the salt.... there are other things. Also assumes user uses same password, and one still has to draw up a rainbow table for every common user. Oh look, easier to just bruteforce one then try the same password on the other. – ewanm89 Dec 25 '11 at 00:44
  • why it's not safe – Muhammad Umer Jun 10 '14 at 16:58
  • let me get this: you generate hash with random # on server then send it to client, where it gets stored in cookies. And when the time comes up you renew this hash on both server and client...it basically acts as second password that doesn't giveaway main password in any form. Right? – Muhammad Umer Jun 10 '14 at 17:53
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.

Jeff Ferland
  • 38,329
  • 9
  • 96
  • 174
  • 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 05 '11 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 05 '11 at 21:56