0

Site Security: Users either login fresh or password is pulled from cookie and they are logged in (or rejected if the cookied password is invalid). + Multiple failed login's leads to rejection.

The passwords are md5 hashed and salted with a random number .

My question is, is this inappropriate?

I understand it is not perfectly secure. Someone could access the user's cookies, crack the hashed cookie and then know that users password.

But, is it reasonably secure and is it somehow unethical in the sense that storing plain text passwords anywhere is unethical?

user187680
  • 663
  • 1
  • 6
  • 20
  • 3
    Storing passwords in plaintext is always a bad idea, no matter where you store them. – Dominic Rodger Jul 09 '12 at 20:16
  • 2
    No, no, no and no. Don't hash passwords to store in a cookie *ESPECIALLY* with md5. – PenguinCoder Jul 09 '12 at 20:17
  • A session identifier, or a longer lasting 'keep-me-logged-in´ cookie, should have _nothing_ to do with credentials. Random is better, validate by storing it somewhere. – Wrikken Jul 09 '12 at 20:19
  • Why should he crack the hash when he can already use the hash for authentication? – Gumbo Jul 09 '12 at 20:26
  • @gumbo the native pass may be used in multiple sites etc. – user187680 Jul 09 '12 at 20:43
  • possible duplicate of [Is it advisable to store a hashed password in a cookie?](http://stackoverflow.com/q/2360861/53114), [Is it safe to store (hashed) passwords in a cookie?](http://stackoverflow.com/q/1563497/53114), [Is it really dangerous to save hashed password in cookies?](http://stackoverflow.com/q/8103721/53114), et al. – Gumbo Jul 09 '12 at 21:02

1 Answers1

6

This is disastrous.

The right (or at least a much better) way to do this is to create a server-side token that is long and random enough to be unguessable and send in the cookie when the user logs in. When the server receives a cookie, check the token against the list to see if it matches, and if so, consider the user validated.

A few miscellaneous notes:

  • You may want to reset that token now and then to keep someone who copies the user's cookies from having indefinite access to your site. If the token is, for example, older than a week, generate a new one and send it to the client and expire the old one server-side.
  • Treat the token server-side with the same security as a username and password, since it is considered an authentication mechanism. Don't just stick it in a table or a file that's accessible to everyone!
  • For any transactions that are destructive or of higher level of confidentiality, make sure you force the user to re-validate via username and password. For example, if the user wants to change their password, or if you use e-mail as a password recovery mechanism and they want to change their e-mail address, or if they want to delete their account, etc., make them type their username and password in to do so even if the token exists.

You might want to check out the OWASP site for more tips and best practices, but yeah, do not send the password in any form, no matter whether it's hashed, encoded, or whatever, to the client.

King Skippus
  • 3,801
  • 1
  • 24
  • 24
  • You know that this is basically what a session handler does. – Gumbo Jul 09 '12 at 20:27
  • No, it doesn't, though a lot of people shoehorn authentication into sessions because it's quick and dirty. As a best practice, I only keep session-specific information in the session handler, and I let the session expire whenever the user closes the browser. The authentication token is kept in a persistent cookie and is only used when a new session starts, and a new session is created from persistent server-side settings. If you try to shoehorn authentication into a normal session, you're going to run into issues if the user uses your site on multiple computers. – King Skippus Jul 09 '12 at 20:36
  • Good answer. Also, this is an absolute must-read: http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication – Polynomial Jul 10 '12 at 14:34