Question

I am writing a PHP application. I want to store user login information in cookies so user’s dont have to log in on every visit.

I want to encode them or obfuscate them so that they cannot be read or tampered with.

What is the best way to do this?

Update:

I am not going to be storing passwords in the cookies, simply a user ID so that I know who they are, but I want this to be encoded or encrypted so no one can spoof other users

Answer 1

The short answer

Don’t do it. You’ll regret it in the long run. Sure, you could encrypt it, but what happens when someone figures out your encryption key. Now you just handed everyones credentials to them on a plate (well, not really, but close enough).

A Better Way Of Doing It

Instead of storing the user-name and password encrypted, why not create a random token and store that with the username? You’d want something sizable, so something like a sha256 hash should suffice.

$randomToken = hash('sha256',uniq_id(mt_rand(), true).uniq_id(mt_rand(), true));

Then, store it in the db along side the user, and send in a cookie to the client (I’d also suggest signing the token as well to prevent tampering:

$randomToken .= ':'.hash_hmac('md5', $randomToken, $serverKey);

Now, when you verify, first check that the hash matches:

list($token, $hmac) = explode(':', $_COOKIE['remember_me'], 2);
if ($hmac != hash_hmac('md5', $token, $serverKey)) {
    die('tampered token!');
}

From there, just lookup the user by the token. If you find one, log that user in.

I’d also suggest changing the token on every single password change.

To answer your question directly

Note: do not do this in live, production code. You can never fully trust data that leaves your web-server. So don’t expose your user’s info like that. It’s not worth it. However, I did add some additional checks (such as signing the cookie) to make it somewhat safer, but you have been warned…

To encode it, I would use mcrypt to encrypt the data into the cookie. Then, I would make a random salt and store it with the user row, and then sign the encrypted data with hash_hmac using that unique salt. That way, if someone intercepts the cookie and figures out the key to crypt, you can still detect the invalid hmac, so you can find tampers.

function generateCredentialsCookie($user_id, $password) {
    $encrypted = encrypt($user_id.':'.$password, $secretkey);
    $salt = uniq_id(mt_rand(), true);
    $encrypted .= ':'.hash_hmac('sha256', $encrypted, $salt);
    storeSaltForUser($user_id, $salt);
    set_cookie('credentials', $encrypted);
}

function readCredentialsCookie() {
    $parts = explode(':', $_COOKIE['credentials']);
    $salt = array_pop($parts);
    $encrypted = implode(':', $parts); //needed incase mcrypt added `:`
    $raw = decrypt($encrypted, $secretkey);
    list ($user_id, $password) = explode(':', $raw, 2);
    if ($salt == getSaltForUser($user_id)) 
        return array($user_id, $password);
    } else {
        return die('Invalid Cookie Found');
    }
}

Note – that’s pseudo-code. You’ll need much more in there to be secure (such as checking for invalid values, making sure it decrypts successfully, etc)..

Do NOT Use Long-Running Sessions!

You should keep your session expiration as low as practical (I typically use 30 minute sessions, but some sites are lower). The expire time is after the last usage, so as long as the site is being used actively it won’t matter.

As far as why not to use a long running session, here are some cons:

• DOS (Denial Of Service vulnerabilities are created

  • Disk space – Each session uses a reasonably small amount of disk space. But when you have a long running session, each new session only adds to the prior total. So with long-running sessions someone just needs to keep visiting your site over and over with a new session id and all of a sudden you’re out of disk-space (assuming a sane disk).

  • Folder space – Each session takes one file in one folder. Most popular filesystems will slow down with a large number of files in a single folder. So if you put 1 million session files, reading or writing to a session file will be slow (very slow). And garbage collection (which cleans old files) will be VERY VERY VERY slow (if it’ll even run at all).

• Session Hijacking vulnerabilities are opened up. This is because the more sessions you have open on the site, the easier it will be to guess a valid identifier (thanks to the birthday attack). The fewer sessions you have laying around, the harder it will be to guess a valid one.

There are likely others, but that’s a quick overview. Instead of long-running sessions, use a signed remember-me token as described above. You’ll be far better off, and far more secure…