in reply to Encrypted Storage of sensible Data in a Cookie

You may also want to try a MAC (message authentication code), whereby you generate a one-way hash (MD5 or similar) of the contents of the cookie together with a "secret key", known only to the server.
When you get the cookie back, you compare the MAC the client hands back with a freshly generated one.
This is to ensure the client doesn't alter the cookie you hand them. Chapter 6 of "Writing Apache Modules with Perl and C" (O'Reilly) is probably useful.
It also recommends using an MD5 hash of an MD5 hash of the data, for reasons I can't remember.
  • Comment on Re: Encrypted Storage of sensible Data in a Cookie

Replies are listed 'Best First'.
Re: Re: Encrypted Storage of sensible Data in a Cookie
by drewbie (Chaplain) on Oct 23, 2001 at 01:50 UTC
    According to the Eagle book, the reason for the double MD5 is that there is a remote possibility that an expoit in the algorithm could be used to break the MD5.

    One should always include a MAC when sending a cookie with any semi-useful or important data. Remember, NEVER TRUST THE CLIENT. :-)

Re: Re: Encrypted Storage of sensible Data in a Cookie
by projekt21 (Friar) on Oct 22, 2001 at 14:09 UTC

    But then I have to store the password plaintext on the server, right? This is not what I wanted.

    But thanks for the hint, I just started reading that book and will hopefully gain some insights.

    alex pleiner <>
    zeitform Internet Dienste

      Almost. You're not storing the users' passwords on the server, but the "secret key".

      Here's some actual (old) code:
      my $secret_key = "BLAHBLAHBLAH"; my $session_cookie = $query->cookie('SessionID'); umask 0066; if($session_cookie) { my $mac; if(($sessionid, $mac) = split("-", $session_cookie)) { ###Ok, the user has returned a cookie, ###let's make sure it's not been tampered with +. if($mac ne md5_hex($sessionid . md5_hex($sessi +onid.$secret_key))) { destroy_cookie($sessionid, "MODIFIED") +; ###Ack. Nasty people return; } else { ###Other checks. }
      This way you're not storing the password, you're just making sure the user doesn't modify the data. A reasonable golden rule is: "NEVER trust the data the user hands you".