Encoding cookies so they cannot be spoofed or read etc_问答_开发者

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

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...

Storing user data in a cookie is the wrong way. You should use PHP Sessions. The only thing that will be stored on the client will be the session id in a simple cookie (that PHP will handle for you automatically). It's already an encrypted string.

PHP will keep track of the user data on the server side.

This will accomplish the desired effect you've described, while remaining more secure than using cookies.

Absolutely in no circumstances should you ever store user credentials in the cookie. You should always assume cookies, as all user input, cannot be trusted.

A couple methods:

If the user chooses "remember me", then simply set the following prior to initializing your session.

session_set_cookie_params(60 * 60 * 24 * 7); //save cookie session for 7 days

Otherwise, store a unique token in the database, and query that token to see if it belongs to a user, and if so, populate their session.

I would recommend the first option though.

Salt cookie before saving. Add user-agent, ip as you wish to extend security.

$cookie_to_save = sha1($pwd . $user_agent . $yourSalt);

upon autologin

if($cookie_saved == sha1($pwd . $user_agent . $yourSalt) ok...

It is simpler to generate a 16 or longer cryptographically secure random number and store this in the cookie. No need for ciphering/deciphering. Use it with a limited validity time checked on the server side (don't rely on MaxAge or Expires). This is a session cookie.

This is very secure since no critical information leaves the server.

The disadvantage of this technique is that you need to create a database index for that session Id and do a database lookup for every request. That might be good enough for most web site as long as the latency is not perceptible and the server loads acceptable.

To minimize server load and response latency, storing the user ID, his role, and the cookie creation stamp inside a secured cookie value is a valid option. No database or cache hit are required to weed out invalid requests and if the user id is compact the index will be small and faster to lookup. But don't invent your own secure value encoding unless you know what you are doing.

The disadvantage of this method is that if someone finds out the key, he can forge cookies. He may then create cookies with different user ids and access their account. So use this method where the risk is limited and access to the key well controled. A dedicated hardware device performing the cipherment/decipherment and concealing the key might be a solution. But that is currently uncommon and expensive. It's latency might be bigger than looking up a random session id in a cache. The later is the simpler and safer solution.

Using public/private keys to secure the value in the cookie, could be used to secure the private key. But that is much more complex to get right, and the latency might be comparable to a system with a simple random cached session id.

Note also that any method using cookies require to use HTTPS. Otherwise a man in the middle or someone spying the data exchanged could easily get a copy of the cookie and impersonate the user.