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?
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.
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.
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.
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]
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;
}
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