Latest Relevance Open Source: encrypted cookie store

  • Posted By Justin Gehtland on January 27, 2008

Aaron just released our latest open source project, EncryptedCookieStore. It turns out that the default cookie session store for Rails is insecure in the worst way: it is simply Base64-encoded (which is French for “plain text”). It is slightly obfuscated, giving the uninitiated a false sense of security, but to anybody who was seen Base64 before, they can probably see the woman in the red dress without even squinting. So, enter the EncryptedCookieStore, a plugin that will truly encrypt the data you are shoving in the cookie. Check it out!

EDIT: Per accurate comments, I need to restate something. The default cookie store is not “insecure in the worst way”; it is, rather, “insecure for the worst developers”. It was not MEANT to be secure (from reads). My point was that, some developers might just assume that the default for sessions would be server side storage, and the element of surprise might lead some of them to Do Bad Things™. That is all; sorry for the confusion.

Comments
  1. tobi — January 27, 2008 @ 05:54 PM

    The rails cookie store works as intended. Its not supposed to be obfuscated, the base64 you mentioned is just done because you cannot deliver valid cookies without it. Its totally tamper proof and hence secure as far as cookie attacks go. If your project requires encrypted sessions you are misusing sessions. That being said, if your project really requires secure and encrypted cookies both you should have a look at HMAC and not simple des encryption. HMAC was created for situations just like this.

  2. Bob Lee — January 27, 2008 @ 06:46 PM

    It should sign it, too.

  3. DHH — January 27, 2008 @ 07:30 PM

    You make it sounds like it was an oversight to have the cookie session data be readable. It wasn’t. It’s that way by design. Base64 is used for serialization, not encryption. What’s important for most applications is not whether the content is secret or not but whether it can be forged (which it can’t be with the Rails cookie store and a proper secret).

    I’m sure there are some off cases where you’ll consider storing values in the session that the user should not know about and your plugin will be great for that.

    I’d take a step back to reconsider why you feel a need to store confidential values in the session first, though, and contemplate whether the session in any case is a good fit for that data.

  4. Clinton Begin — January 28, 2008 @ 02:43 AM

    You guys have to be really careful how you position this and be sure to educate your users (with documentation). Otherwise you’re at risk of doing more of a disservice than anything…

    • Make sure developers know that if their goal is to encrypt data during transmission, they should use a SSL cert signed by a CA (nothing here preventing a MITM attack).
    • Make sure developers know that there’s still nothing that guarantees the validity of the cookie (e.g. I can still copy the cookie from someone else’s machine and spoof their session on another computer).
    • Make sure developers know that if their goal is to keep the information from the user, they should not put it in a cookie. I’m a firm believer that nothing should be in the cookie except for the session id, and in some rare cases cached data that is visible on the site anyway (i.e. no security requirement)
    • +1 DHH…. Base64 is for encoding data in for transmission and storage in systems intended for or limited to plain text (e.g. HTTP)—reducing the 256 possible values of a byte to 64 printable characters (and thus increasing size by 33%). There was never any intention for it to be a form of encryption or obfuscation.
    • Consider using AES/Rijndael rather than DES.

    There may be a use case for it (I personally can’t think of one) but it’s really important that you educate potential users so that it’s not misunderstood and unintentionally abused.

    Cheers, Clinton

  5. justin Gehtland — January 28, 2008 @ 06:09 PM

    Clinton—absolutely. The docs will clearly state the expected use case. And, I definitely wasn’t trying to imply that base64 was anything other than a transmission system for extended charsets; however, after teaching web development, it still amazes me how often people believe that because the string is obfuscated (in this case, merely transformed), it is safe from reads. Thanks for the comments!