Other ways of protecting cookies

Question

I've been thinking a lot about this recently, and I wanted to know if anyone has thought of/implemented any intuitive ways of securing cookies from manipulation. I've always used the "sign it with a hash and check against the hash later" approach, but it doesn't strike me as a particularly brilliant way of going about it, and just like all good programmers I want to find a better way of doing it.

As for why cookies specifically, well, I don't use native sessions - I hate to touch the filesystem. Cookies are a really quick way of storing data for later, and even with things such as user authentication I'll chuck the user ID in the cookie, perhaps along with the username/email and a signature, as well as a random hash for good measure.

What clever ways have you used to secure your cookie data?

Answer 1

With hashing you need to be very careful that you have included a salt, otherwise it can be trivial to determine a matching hash.

Thus, to protect against accidents, it's often appropriate to also encrypt the cookie.

-- edit

You may also like to learn about 'HTTPOnly' cookies: http://www.owasp.org/index.php/HTTPOnly

Answer 2

Uh, you're storing the UserID in the cookie and giving the user access based on that value? You're asking for trouble. Server session based data implementations exist for a good security reason: Store a session identifier in the cookie and access the UserID from the record on the server where the client can't tamper with it.

Cookie security to protect against client tampering is pretty much a lost cause. Given enough time, someone will figure out how to crack it. Don't give clients that opportunity. Cookie security's only purpose is to make sure client's cookies aren't stolen.

Answer 3

Signing the cookie with a HMAC is a perfectly reasonable way to do this. HMAC essentially rolls a secret key known only by your server into the hash, so even someone who knows the algorithm can't generate a HMAC that will be recognized as valid without knowing the key. Just using a plain old hash is trivially bypassable because the attacker can generate valid hashes of their own data, and all the "salt" in the ocean won't fix that.

Even if you used a session ID instead of storing meaningful values, you still would have to be careful that an attacker couldn't predict another valid session ID, and send that to you instead, thus hijacking the other user's session. I believe there was an actual exploit against Hotmail that worked this way.

Encrypting the cookie only helps you if there's something in there you don't want the user to see. Even worse, encryption without an HMAC gives a false sense of security because a cookie that is merely encrypted is still vulnerable to manipulation of the ciphertext to change parts of the plaintext.

So in summary, don't just hash it, use an HMAC!

Answer 4

On the Security Now podcast (i forgot which episode), Steve Gibson talks about doing something like this and i think the system he recommended was to make the contents of the cookie a good hash, then make that hash a key in your local database where the value(s) is(are) all of the info that it needs to store.