in reply to Re^7: Is this a secure way to prevent cookie tampering
in thread Is this a secure way to prevent cookie tampering

Chosen plaintext attacks don't really apply since the data in cookies come from the server. The server doesn't usually encrypt data fed from an attacker. Modern secret key ciphers are resistant against chosen plaintext attacks and brute force tends to be the best attack. They are, by far, the most secure part of any system.

Compress before encryption means to doing the compression before encryption, because doing afterwards is useless since ciphertext is uncompressable. It does not mean you have to use compression. Compression does provide some benefit by hiding the plaintext a little bit. Since cookies are so small, compression isn't all that useful.

I would say encrypting sensitive information in the cookie is silly. Either the info is sensitive, and shouldn't be put in a cookie, or it isn't and can be plaintext. For most applications, authentication is more important than hiding secrets. For example, a cookie that contains a username for authentication, leaking the username to eavesdroppers is a privacy problem. Allowing someone to tamper with or replay the cookie is a major breach.

  • Comment on Re^8: Is this a secure way to prevent cookie tampering

Replies are listed 'Best First'.
Re^9: Is this a secure way to prevent cookie tampering
by exussum0 (Vicar) on Jul 01, 2004 at 16:44 UTC
    Yes, cookies come from the server. But the point of encrypting and all this rigmarole, is if you put user data, other than a number, inside a cookie. Assume that not a password, but if someone's age, maybe their login and some other info is in there for SOME reason. Either for performance reasons, not having to deal with clustering.. there is always a reason someone may want to do it. Heck, even a timestamp.

    Yes, compress before encryption. Not after. I thought I said that, but if I was confusing, yes, we agree on that. Compression for size doesn't help all that much, 'cause you are right. Small data won't compress that much smaller percentage wise, but you still get the obfuscation, which is a bigger selling point.

    But, the point of the exercise is, giving people some data and at the same time, keeping it private for some "good" duration. Not forever. given infinite time, any encryption scheme would be breakable, except for one way hashes. After all, a hash doesn't guarantee against collision... usually.

    And yes, allowing modification of the data in the cookie is bad. More reason to compress, md5 the compressed part, take the two and encrypt that together. Thus, if you change one block, either the md5 gets mucked, or the data gets mucked. But the md5 of the data block will no longer be valid. Mathematically, you'd be more likely able to brute force and may even cryptoanalize (horrid spelling there :) the data before you can generate one that respects an md5, compression and encryption all in one.

    The comperssion and what not does make things harder. I think we agree on that. But if you have to put some data out there because of some requirement, it's best to do it the best way you can do it.

    Bart: God, Schmod. I want my monkey-man.

[reply]

In Section Seekers of Perl Wisdom