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