2

Possible Duplicate:
PHP storing password in cookie

In a login system, if a user want to stay logged in, then the password needs to be stored in the browser cookie. I have been gone through many previous questions on SO, and found out that its not any secure to store the password in the browser cookie. I wonder if I do sth like

$string = 'snfcikkfbnvekrew';
    $salt = md5($passwrod.$string); 
    $password = md5(sha1(md5("$salt$string$salt")));  //or some other random sequence of encryption functions

I'm just curious to learn what kind of attacks can be performed if someone accesses the cookie?

Community
  • 1
  • 1
Jay
  • 10,831
  • 9
  • 26
  • 33
  • 1
    Part One of this question is here: http://stackoverflow.com/questions/5232908/php-storing-password-in-cookie – awm Mar 08 '11 at 14:06
  • md5 and sha1 are NOT encryption. they're hash functions. Think of them as meat grinders. Very easy take a cow and make hamburger - (virtually) impossible to take the hamburger and make a cow. – Marc B Mar 08 '11 at 14:10
  • 2
    So, uhm, your previous question was answered with don't do it; and now you are asking for the best way to do said thing? – mario Mar 08 '11 at 14:14
  • @mario: The answer with highest votes was "Store a salted hash of the password in the cookie". Thats why i asked this. – Jay Mar 08 '11 at 14:17
  • 1
    Then maybe you should accept that answer :D – Adam Hopkinson Mar 08 '11 at 14:26
  • Don't hash your password like that. See why [in this answer](http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms/4948393#4948393)... Never feed the output of a hash function directly into the input of another. You're not getting any benefit, and you're actually making it easier to crack... – ircmaxell Mar 08 '11 at 15:05

6 Answers6

9

Why do you need to store the password in the cookie? Why not some other user identifier, such as an internal user ID or some temporary value of some kind?

"Store" and "password" are two words that should very rarely be used together, and when they are that use should be scrutinized carefully.

David
  • 208,112
  • 36
  • 198
  • 279
  • 2
    Agreed. You want to store a salted hash or *something* which you know and can easily recalculate but can't easily be guessed. It would be equally valid (and *way* less risky) to use the timestamp at login salted with your favorite math teachers' name and the phase of the moon. – CaseySoftware Mar 08 '11 at 14:26
6

If someone accesses the cookie, even if it's hashed, they have all the same access the user of your site would have until the cookie expires. Even after it expires though, unless the password has changed on the server, the same hashed value could still be used to login.

Rather than store the password, if you wish to permit them to visit again without logging in, set a cookie with some other random token value that is stored with their user account. On every page visit and form submission, you can regenerate and store a new random token and reset the cookie to the new value. That way, the stored value is constantly changing so if a malicious user got ahold of the cookie in transit, it may have already changed by the time they are able to use it.

Finally, if you are going to be storing any value for logging in later, you should be doing it over SSL and only sending the cookie over SSL.

Michael Berkowski
  • 267,341
  • 46
  • 444
  • 390
4

Use a $_SESSION instead of concocting your own cookie system, and instead make the session last a while:

// keep user logged in 6 months
session_set_cookie_params ( $lifetime = 6 * 30 * 24 * 60 * 60 );
session_start();

if ($login == TRUE) {
    $_SESSION["user"] = $user_name_or_id;
}
mario
  • 144,265
  • 20
  • 237
  • 291
  • 1
    (Needs a bit more configuration and is inadvisable for high visitor traffic, since the session store will grow continually.) – mario Mar 08 '11 at 14:25
  • 3
    To be fair, do we really think the OP is talking about a high traffic site? For most purposes, PHP's built-in session handling is just fine and rolling your own is frequently a waste of time, or worse. – philistyne Mar 08 '11 at 14:38
  • [Do **not** use long running sessions](http://stackoverflow.com/questions/5009685/encoding-cookies-so-they-cannot-be-spoofed-or-read-etc/5009903#5009903). There are better ways of doing it than making sessions last that long... – ircmaxell Mar 08 '11 at 15:48
  • 1
    @ircmaxell: That reads like a generalized advise never to use sessions. You are susceptible to the mentioned problems depending on the DoS request amount, not actually storage time. And here in this particular case the session use and creation is actually dependent on a [x] stay logged in checkbox *and* a successful login. Session hijacking would actually be less likely the fewer authorized sessions there are. – mario Mar 08 '11 at 16:12
2

I've used with great success the method explained in "A Secure Cookie Protocol" ( 6 pages )

http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

Daniel Luca CleanUnicorn
  • 1,087
  • 1
  • 12
  • 30
1

Never ever try to store password in the cookie.It had better store session_id in the cookie, ,while password in the session on server. You cannot imagine how easy hackers decode the string you just encoded.

soasme
  • 392
  • 5
  • 11
0

The pasword itself doesn't need to be stored in the cookie as you'll never be able to retrieve it anyways and reverse it to proove it's the right password. but if you want to use some algorithmic combo of password/email/recId/whatever that you can check internally, then go ahead and salt your string up however. I would likely use a combo of some unencrypted or reversible UID along with a unique and recreatable encrypted key so I could do a lookup of the record in question and validate such as

select 1 as loggedIn from userTable as u where u.uid=[cookie.uid] and md5(concat(u.email,u.accountcreated,u.lastlogin))=[cookie.hash]
FatherStorm
  • 7,133
  • 1
  • 21
  • 27