Designing a secure auto login cookie system in PHP

Question

I want to have an auto login option check for a user. Basically that means a cookie will be stored on the client side.

Now the question is, how do I make it secure s

Answer 1

For most auto-logins I know, there is a separate table to store logged-in sessions. Each auto-login session is assigned a hashed key as an identifier, the key is considerably long and virtually not possible to spoof. If you don't want users to be logged in cross-ip even with a valid code, try this.

function gen_uniqueIdent($length=32){
    $alphabet = str_split('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ123456789');
    $key = '';
    for($loop=0;$loop<$length;$loop++){
        $i = mt_rand(0,count($alphabet)-1);
        $key.= $alphabet[$i];
    }
    return $key;
}

Assign this value to the user cookie upon login. Then store this into the db:

function save_ident($identFromFunctionAbove,$authenticated_user_id){
    //hash this with something unique to the user's machine
    $hashed = md5($identFromFunctionAbove . $_SERVER['REMOTE_ADDR']);
    /** Some actions to remember this hash **/
}

save that into a database correspinding with a user identity like user_id.

Now upon validation of the user cookie, you can simply:

function validateCookie(){
    $ident = $_COOKIE['yourCookieName'];
    $hashed = md5($ident . $_SERVER['REMOTE_ADDR']);
    /** Check if this hashed value exists in db, if it does, authenticate user **/
}

You'll also need to remove the sessions after they expire or the user explicitly logs out.

Of course this is very simple, and doesn't account for md5 or ident collisions. Still, getting two 32-character random generated string to be the same as one previously generated is pretty slim a chance.

Answer 2

The way I have previously done this is storing the MD5 hash of the password not the actual password.

On the server side you need to check if the login is coming from a cookie and then check if the hash is the same as the password in your database after its been hashed through MD5

That way if someone hacks the users computer they can never know the value of the password however the can still use that cookie to authenticate to only your server.

You can make this more secure by making the cookie expire after x days so if the cookie is stolen the theif can only get access for that period.

At the end of the day the most and only? secure method is make the user login each time

Answer 3

The more secure you want this infamous cookie, the more trouble it's going to be for you. If your users should be particularly secure, you will have to go with the most troublesome approach.

You should only accept this cookie with https if you want to be as secure as possible. If the cookie is accepted over http, it can be sniffed and stolen.

I would recommend that the cookie have no user data at all (a token, as you suggested). This will, unfortunately, require another table. When a user logs in and chooses "keep login," create an entry in this table. The entry can be any meaningless value (such as md5(uniqid('', true));. This token can be unique in the DB and mapped to a user's ID.

When a user visits your website, you can check the value of that cookie and get the user it belongs to and log them in. At this point, you destroy the old token and create a new one. "Destroy" can mean many things. You can delete it from the DB entirely or have a flag that disables the token. You may want to allow the same token to be used multiple times in case the cookie is received but the authentication doesn't go through for some reason, but I think this is insecure. You may also want to store the timestamp of the token and only accept it if it's been some limited period of time (30 days for example).

As your friend points out, you can store other information such as user agent, IP address, etc., but these may change even with the same browser being used (especially with mobile) and if a user's persistent login is not accepted because of this, it could be jarring and inconvenient to them.

If you really don't want to create another table, then you will have to store some way to acquire the user's ID from the cookie value. This is less secure.