too long

Im currently implementing a "Remember Me" system for a web project. After reading a few (albeit not so helpful articles" I came up with this system to prevent a cookie from being used to access an account other than that of the user that is was assigned to:

  1. User logs in and checks the "Remember Me" box.
  2. Users email and password combination are authenticated. Because the remember me function is checked a random salt 128 characters long is created and stored in a table along with the users userid. A cookie is set containing a hash of the users userid concatenated to the hash of the users userid and salt.
  3. When the user revisits the webpage the userid and hash are separated and the hash is check against a hash generated from the salt and userid stored in the database. If the values match then the user is the user the cookie was assigned to and the user is logged in.

If there are any issues/improvements that can be made please point them out Im always open to criticism :)

Yes that sounds OK but why reinvent the wheel? You are describing Sessions. You may as well use the functionality built into PHP.

http://php.net/manual/en/features.sessions.php

Nope, it's overcomplicated.

  1. Create remember_me (or whatever table name you like) table in database with columns user_id | hash

  2. After user is authenticated with "remember me" option generate random hash and put it in table with correspondent user_id and in user's cookie

  3. When user comes to a page and is not authenticated and has "remember_me" cookie - find user_id by cookie value

The important thing: there is no valid reason ever to rely your remember_me client data on real user's name, email, password or anything

PS: you could append the client data with user_id value if you wish

Your system has a good start, but is still very vulnerable to hijacking (if someone takes the hash that is stored in the cookie, he can easily take over the session).

Anyway, here are some good posts about this very same topic:

I think you should start by reading those links.

There is indeed not a complete foolproof system (check the 3rd and 4th links, they provide some interesting extra things; user-agent is some kind of identifier you can use as well). I can suggest you to use some kind of OpenID provider (or multiple) to get all the security stuff out of your hands. If do want to do it yourself: you'll have to weigh the pro's and con's to achieve maximum security or a little less.

Like others have said you have a good start. I would recommend creating a table that stores some of the cookie information, in particular:

user_id
random_hash
ip_address
date_created

Then when the user logs in, you generate a hash like you said and insert that data into the table and create the cookie storing their user_id & the hash.

When the user returns you check the hash and ip_address and look for a match. If one is found, authenticate said user_id AND remove the used hash and generate a new one for next login. I'm sure you can see the benefits of doing this way.

Also - make sure your using SSL and (important) never allow a user to change or view any key information without providing a password!

Cheers!