PHP: Cookie/Session "Remember Me" Feature

[apinomus]

I'm making a user-login based system for a site I am developing and want to give users the option for the browser to remember their login info like many sites do using cookies. Between maintaining the session on the server, how is the written cookie used when the user returns--in what order should my function process the data stored in the cookie, and which info should I store in the cookie to authenticate them if they return after their session has expired?

 

[apinomus]

Bump

 

[kamper]

All you need to store is a something that identifies them, that can't be forged. As a simple (non-secure) example, you could put their user name in a cookie. Then, when someone who does not have a session requests a page, check the cookie for their user name, go through the log in procedure as if they'd supplied a password and then continue as normal. Of course, the problem is that anyone can create a cookie with a certain user's name and log in for free then.

You need some piece of data that no one else can guess. If you know no one will see your code, make a single, long, randon string. Concatenate it with the username and do some sort of a one way hash on the result (like sha1). Store that in the cookie and when you analyze the cookie like above, use the same string and algorithm, compare the results and if they match, they're in. (You'd also have to store the user name in plain text in the cookie or another one so that you know who you're trying to authenticate).

If people might see your code and get your random key, you've got to generate it on the fly and store it, maybe in a database with one key per user or something. Since you've probably already got password hashes in the database, you could use that as a key. Just be sure you don't accidentally expose something that would allow someone to crack a password with the data from a cookie you hand out.

 

[apinomus]

Sounds like a good idea kamper, thanks for the suggestions.

 

[imported_LoKe]

Instead of risking using password hashes, you could simply md5 their ip address, or some other simple string, upon registration and store it along with everything else. That way, when you pull it, you're not risking anything.

 

[kamper]

An ip address is a bad idea. 1) It's not reliable. People with laptops can change their ips quite frequently. Same for people on dial up. When it changes, they can't log in anymore. 2) It's not secret. It's easy to guess what ip people were using to visit a site. Heck, if you're behind the same nat firewall, you've got the same ip.

I'm not saying using the password is a particularly good idea but it's not extremely risky. First you've got a hash of a hash, and hopefully it's something stronger than md5. Second, if they do manage to crack it, it doesn't matter if they get the password, they can log in without it. The point is, it's got to be something nobody can guess. The best thing I can think of is a relatively long random string, generated for each user.

 

[Zugzwang152]

I wasn't aware using a built-in randomizer is better than hashing with a secure algorithm... 😕

 

[kamper]

I never said it was. But it's pointless to use a secure hashing algorithm on something that's not secret if you want to prevent people from duplicating the cookie. You need to run the hash on something that is random.

Edit: now that I think about it, the hash is actually completely useless if you have a strong, per-user key. You may as well just hand out the key because the hash of the key can't have much more entropy (whew, there's my big word for the day 😛). This is starting to feel a lot like ssh public key authentication...