hi, is there a safe way of storing passwords in cookies in php?
or is it not recomended?
thanks
+1
A:
The user is able to change his cookies at will. If you want to "trust" data in PHP, you need to store it on your server, and not on the user's machine. Cookies can also be intercepted through XSS attacks and browser bugs (practical but relies on some another security hole), in addition to sniffing it out on the wire (more theoretical but will always be a flaw in this scheme).
Dragontamer5788
2010-10-13 22:45:35
A:
It's not generally recommended, but possible. You could encrypt the cookie's contents with the mcrypt extension.
Alex Howansky
2010-10-13 22:46:18
A:
Not recommended. Ideally a cookie is just a unique identifier that can be used by the server as an index into a database table (or other structure) which maintains the required data.
It is possible to encode data in the cookie, but I wouldn't be doing it for anything sensitive.
When it comes to passwords, my own opinion is that they shouldn't be stored at all. Only the password hash should be stored.
Andrew Cooper
2010-10-13 22:47:25
A:
One could possibly hash a password into a cookie, and check that hash against the hash in the database. That's theoretically safe-ish. (You're hashing, aren't you? With a salt? If someone break into your database and you're not, all your users are doomed.)
Regardless, it's still not recommended. Putting information, even when hashed, out into the open is a bad idea overall, when it's a relatively simple matter to store the data yourself and tie it to a generic session ID that doesn't offer any information about the actual password to anyone who could possibly steal that cookie. $_SESSION makes that wonderfully easy.
Matchu
2010-10-13 22:47:51
no, im pretty new to this, you know of any good info links on hashing?
Adamski
2010-10-13 22:52:16
A:
Hi, you can hash a cookie's data using sha1() or md5() but the best way for it is use session for storage a user's data.
Oskar Marciniak
2010-10-13 22:47:53
A:
This is not recommended...
... even if encrypted. Storing this information on a client machine gives them the opportunity to compare cookies in the hopes of decrypting. Worse they could sniff a cookie from someone else and then masquerade as that user!
What is recommended is having the user login through a secure connection and sending a session cookie in response. The session cookie contains a session id which PHP will automatically map to a session file on the server. You can then store a user id in the session. After a short time, the session should be expired.
Sessions are automatically managed by PHP and you should take advantage of it.
Here's a tutorial on how to use PHP sessions.
webbiedave
2010-10-13 22:48:17
To be fair, sessionIDs are simply cookies themselves. If they can sniff an encrypted password and do a replay attack, they can sniff the sessionID and also do a replay attack. For true security, you need HTTPS based authentication. For stuff that don't actually need real security (ie: like the front door to your house. Sure, picking it is possible but you just need some sort of barrier to entry)... session variables are fine.
Dragontamer5788
2010-10-13 22:56:11
True Dragontamer5788. But using sessions that expire frequently **greatly** lessens that chance of sniffing when compared to a never changing cookie containing a password. If he's writing,say, an application for accessing a bank account, then it should be HTTPS **the entire session**.
webbiedave
2010-10-13 22:58:34
Of course, but that technique can also be applied to cookies containing a password. Encrypt the cookie and append the current date/time before you hash, and you'll get similar levels of security. Overall though, in PHP, it tends to be easier to use sessions, and it still doesn't really secure your application. (again, needing HTTPS). My argument is more of a formality anyway, I do agree that sessions are the simplest way to do it.
Dragontamer5788
2010-10-13 23:58:08