Tobi, Bob and David are all exactly dead spot on right. The Rails cookie store works as designed, data stored there should be tamper-proof and signed, and you are indeed the poorest kind of web programmer if you are assigning strong, valuable data into a cookie. Right, right, and right again.
However, the rub here is that:
- Rails is an awfully popular web framework,
- used by all kinds of developers, from neck-bearded Unix geeks down to baby-bottom-smooth-chinned highschool geeks,
- for all kinds of applications.
Given that the cookie store is the default session store, and that people either accidentally or on purpose store all kinds of goop in the session (often transiently, sometimes for the length of the session), then it behooves people to have a way to default to a more secure version. That’s all the EncryptedCookieStore is for: guaranteeing that if you screw up your app, you don’t also screw up your users.
So, in order to be clear: Relevance in no way suggests that you should store anything of any value in a cookie. In fact, we’ll shake our heads in disgust and drag you out behind the woodshed if we catch you doing it, you’re darn tootin’. But if you want to make sure that you don’t accidentally reveal something through this mechanism, defaulting it away might be useful.
And I did not mean to imply that the Rails team was either negligent, ignorant, or foolish for implementing the cookie store the way they did. I understand the reasoning well; our plugin is a safeguard against accidental misuse, not willful stupidity (we hope ;-) ).
+1 all the way. I simply wrote this as a safety net for anyone who would like to use it. If I felt in any way that this was a design flaw in Rails I would have suggested and / or provided a patch to the Rails core team.
I appreciate the comments, but I think using EncryptedCookieStore to protect yourself from accidently placing the nuclear launch codes in the session is overreaching. If you’re using the session so heavily that you’re constantly yanking things in and out, I’d again go back and revisit the reasoning for why that would be.
Most applications out there need to place exactly one value in the session: The user id for the person logged in. Anything else than that should require careful consideration. But if you do go with just the user id, which I would consider a best practice, you would certainly not need the EncryptedCookieStore.
All that said, I certainly don’t want to rule out the possibility that edge cases exist where you DO want to place the nuclear launch codes in the session. I have a hard time coming up with an example off hand, but never the less.
For those cases, I think having an EncryptedCookieStore is a very fine idea. You could certainly also just go with a database-backed store, but if your encryption is strong enough, a cookie store may be well and fine too.
I just want to push back against the idea that the session is such a frequently used device that you need to protect yourself preemptively from accidently placing big secrets there.
Regardless, thanks for sharing the work on this. For those off cases where it might be relevant, it’s great that someone took the time to build and share this.
Also, I think you might want to revisit the alarmist wording in the original post: “It turns out that the default cookie session store for Rails is insecure in the worst way”. Someone just reading that in isolation would get a quite distorted picture of the how and whys of the cookie store.
DHH—edited. Thanks for the continued feedback!