views:

278

answers:

4

I've read some articles and questions on SO (e.g. here) that say you shouldn't store a user's password in a cookie. If the password is salted and hashed, why is this insecure?

In particular, why is it less secure than using sessions, the alternative usually suggested? If the user wants to stay logged in then surely this new cookie (with a session ID/hash) is exactly as secure as the one with the user's password? If the cookie is "stolen" on some way the attacker can log in as the user in the same way.

EDIT: The main crux of the question is the part about the user staying logged in, i.e. via a "Remember Me?" checkbox. In this case, surely there is only ever one session?

+4  A: 

Among other distinctions, if a session is stored, you own this one session. If a pwd is taken, you own every session of that user from now on.

DVK
But surely that's irrelevant if the user wants to stay logged in permanently? There is, and will only ever be, one session.
DisgruntledGoat
Not necessarily. That's certainly the easiest way to implement it, but not the only one. For instance, you could have a rotating session key. If someone stole one, they might get the next one too, but that'd kick the original user out who would then relog in and your attacker is again left in the cold.
Matthew Scharley
+3  A: 

Sessions are usually keyed to IP addresses at some level somewhat preventing session theft.

Beyond that, the session ID doesn't contain any personal information; your password, even salted and hashed does. Passwords, salted and hashed as they may be, can be reused; session ID's can't. Once the session is over, it's over, you need a new session ID to be able to impersonate the user again.

Matthew Scharley
+11  A: 

By putting the hashed password + salt in the cookie, you:

  • Open up an unlimited bruteforce vector
  • Allow the cookie to be copied and used by anyone (it always lets access; whereas a session does so for a period of time).
  • Make it harder to change hashing schemes, if it becomes relevant

Further, you generally need to store something else, to identify the user (like their user id, so you can look up their password and match it). This may lead other obscure problems.

So you're best just going with the session id approach.

Noon Silk
I see your points. However, isn't there a brute force problem with sessions? If you have millions of active users (e.g. Facebook) then you could try random hashes until you get one that works? I suppose they're tied to IP addresses?
DisgruntledGoat
+1  A: 

How about letting someone else deal with and think about all these issues for you? That is, use OpenID, Windows Live ID, Facebook Connect, etc.

Dan