Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

by Anonymous Monk
on Jun 30, 2004 at 18:35 UTC ( [id://370864]=note: print w/replies, xml ) Need Help??


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

TIMTOWTDI
Yes, there is more than one way. Many of the ways are booby trapped, though. It's best to be somewhat less offhand about proposing new cryptographic protocols.

if you are worried about plaintext attacks, gzip the plain text to turn it to binary first.
Binary data is still plaintext to a cryptographer. Gzipping can reduce some redundancies in the plaintext, but it also introduces its own structure.

Replies are listed 'Best First'.
Re^5: Is this a secure way to prevent cookie tampering
by exussum0 (Vicar) on Jun 30, 2004 at 19:00 UTC
    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.

      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.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (8)
As of 2024-03-28 11:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found