'Digitally signed' suggests some sort of public-private key arrangement. `man ssh-keygen` will tell you more than you probably need to know about how to generate an encrypted key pair. You can use this tool to create keys for an encrypted web browser connection, or to permit password-less connections using the ssh protocol.

I've never heard of a 'digitally signed cookie' though. A google search on the quoted term turned up only nine hits, including two for your question. Google's spiders are quicker than my review of the newest nodes link, apparently.

-- Hugh

I don't see the point of having a digital signature in a cookie under normal circumstances. Granted, you can verify the signature to ensure that the server signed the cookie. But, most often, the only purpose of the cookie is to point to a persistent file on the server. If the files are named randomly and the users can't get a list of the names of the files, they can't just make up cookie values anyway.

If you need to sign the cookies because you are going to store actual data in the cookie itself, instead of having the cookie point to a file on the server that contains the data, then you will need to sign them. But that's not commonly done. Would it matter to you that the users can just delete the cookies?

A digital signature is just a hash digest (sha1 or md5 usually) that has been encrypted. Cpan has lots of hash and encryption packages. I'm partial to OpenSSL, which seems to have a fairly large user base, so I would try the Crypt::OpenSSL::* modules first.

Good luck. You will need it. Remember that cryptography has a long sad history of systems that went into production and were then found to be startlingly weak due to minute flaws in the design. There is no substitute for careful design, and also no substitute for adequate peer review.

The (compelling!) reason for “digitally signed cookies” is a so-called session riding attack, which involves (in its various forms) the use of replayed, forged or tampered cookies. Many ill-designed systems assume that, if you present them with a “session ID” cookie that appears to be of the correct format (it could just be an MD5 string...) this ID must represent an existing or we-should-make-one-now session. Or perhaps, that user's identity. A captured token might be replayed, e.g. by a rogue script running on that user's machine, and thus gain rights it should not (still) have.

There are many cookie-validation schemes out there on CPAN now, so you don't have to create this from scratch, but the basic idea might be (for example...) this:

1. To the basic cookie value, append:
   • A random integer, called salt, which is included in the cookie in its unaltered, unencrypted form.
   • A guard value computed (say) by a secure SHA1 (not MD5...) hash of the cookie, the salt, and a very-long random string known only to you and provided by a sub so that its value never exists in any potentially dumpable variable-namespace.
2. When the cookie is received, a rigorous regular-expression verifies that its format is exactly as it is supposed to be, then separates it into its three component parts.
3. The same hash-algorithm is applied and the result is compared to the guard-value. It must match exactly.

This scheme can be used to append other information to the cookie, such as an expiration-time. “Guard digits accompanied by a long, random, secret string” can also be used to produce masks, so that (say) the true value of a session-ID can be concealed.

Remember:   in CPAN this sort of thing already exists. Cookie-validation (and POST-data validation!) should be provided at a very high level within your application framework so that these services become reliably available to every part of your application without further concern from you. (If it were something that you had to be conscious of, you'd miss something and an exploitable “hole” would be awaiting discovery. Because rogues use automatic scripts to test such things, it would be discovered.)

Don't “trust” ... verify.

E.g. for a web site having a shopping cart (i.e. list of items selected for purchase), encrypting and digitally signing the shopping cart and send it to the web client means that the web server does not have to keep track of who's buying what. When the person in front of the computer decides to go to checkout, the whole shopping cart is sent back to the web server, verified and decrypted.

The subject was discussed here (Security Now podcast, Episode 110).