Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^5: Is this a secure way to prevent cookie tampering

by exussum0 (Vicar)
on Jun 30, 2004 at 19:00 UTC ( [id://370872]=note: print w/replies, xml ) Need Help??


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

If you dont' obfuscate your original data, either by zipping, xoring, bitshiffting or what-have you before hand, regardless if you use a MAC or you use encryption without MAC, you still have the possibility of plaintext attacks.

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

Replies are listed 'Best First'.
Re^6: Is this a secure way to prevent cookie tampering
by iburrell (Chaplain) on Jun 30, 2004 at 19:16 UTC
    What do you mean "plaintext" attacks? There are three different attacks that need to be worried about with cookies.

    First, is hiding any confidential data. The simplest way is to not put confidential data in the cookie and keep it in local storage. The cookie becomes a key to find the local session data. The next best is to encrypt the data with a secret key. Compression is just obfuscation and not secure.

    Second, is protecting the info from tampering. MACs are perfect for this because only those with the secret key can generate or verify the MAC. The plaintext can be read but not modified. For cookies that are just keys, the keys can be chosen from a large enough space that modifying the key results in an invalid value.

    Second, is preventing replay attacks, from someone recording the cookie and using it later. Using SSL to keep the cookie from being known is the best solution. Including expiration time in the cookie or session is another solution.

    Finally, is preventing tampering with the cookie. Generating cookies is a similar attack. MACs are a good solution since they can only be generated or verified by the secret key. An authentication cookie with a username, expiration timestamp, and MAC is perfectly good if user names don't need to be kept secret.

      plaintext attacks.

      Compress before encryption. Not in place. Please reread my node.

      You typically dont' want the private data read as it may contain sensitive information.

      Of course, encrypting the line is wanted. But the point is on just having a cookie outside of the wire transmition. After all, encrypting any line will make it more secure. :)

      Secret keys, regardless of MAC, can be broken. Don't forget that key point.

        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.

        You linked to a page titled "What is a chosen plaintext attack?" I don't see how compression is going to protect you from chosen plaintext attacks. If someone can choose plaintexts that will break your cryptosystem, it's not that much more work for them to choose plaintexts that compress to strings that also break the system.

        The page also displays a lack of understanding of what a chosen plaintext is, and ignorance of the history of the Enigma machine. Find a new source of information.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://370872]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2024-03-29 07:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found