Beaker 0.9, cookie-stored sessions, and crypto 5
In the latest 0.9 release of Beaker, I’ve finally added cookie-side session storage. I was a little bit moved to finally do this by seeing that Rails 2.0 had added cookie-side session storage, and heck if I was going to miss out!
A few changes from how Rails 2 did it though, I was definitely not content to store all the data in an end-user visible form in the cookie. That only left encryption as the next logical choice, and that quickly led me down a path of quite a bit of cryptography research.
The world of cryptography is a constantly evolving and rapidly progressing field. New papers are coming out all the time with new research on ways to break, or ‘wound’ a particular encryption scheme. Providing a weak form of encryption in Beaker would be worse then not having it at all, since it’d lead someone to falsely believe the session data was secure.
After initially going with an RC4 cipher implementation, I got ahold of some crypto people that are actually in the field, and the unanimous opinion was to use AES encryption in Counter Mode, also referred to as AES-CTR along with a signature to prevent tampering (you’d be amazed what you can do to encrypted data, and it’d still technically decrypt). This led to a slight increase in requirements unfortunately, as pure Python based AES encryption is a bit slow. This means that using cookie-based sessions in Beaker requires the installation of PyCrypto, which includes a C extension (making cookie-based sessions faster than file-based, memcached, and db-based sessions).
The final solution in Beaker uses 256-bit AES-CTR with a 256-bit HMAC for authentication purposes. It’s fast, secure, and scales across a cluster without a problem. It’s not for everyone of course, cookies are rather severely limited in size, so if you’re just storing a few small tidbits of information in a session, for example:
- a user id
- some flags about the users status (logged in, etc)
- a flash message
Then cookie-stored sessions might be perfect for you.
Update: Forgot to mention, in the future, Beaker will probably use pycryptopp instead of PyCrypto since the PyCrypto library’s AES-CTR implementation isn’t as efficient as it could be, and will be using VMAC’s instead of HMAC’s for even more speed. Plus, apparently Andrew Kuchling isn’t maintaining PyCrypto, as there’s quite a few patches for it sitting unanswered on the sourceforge and launchpad bug trackers.
That’s a cool feature, but shouldn’t the crypto be optional? Especially if it requires an unusual C extension, and has a performance hit.
I could see three useful options:
1) no crypto 2) MD5 checksum 3) the full-on encryption that you’ve implemented
With an implementation like that, that would save me custom cookie code that I just wrote. (Granted it’s only a few lines,so it’s not a big deal… but still…)
Thanks for the addition!
I was considering that at first, except I was a bit concerned about the increased attack vectors of having something in the clear.
For example, if you snoop the encrypted cookies, looking for an ‘admin’ user’s cookie to steal, you’ll never know which one is such a cookie. However, with merely signed cookies, you can watch them till you see a cookie with the session info set that you want to steal, then hijack that session
So I consider an un-encrypted cookie to be a riper target for cookie hijacking, since its easier to see whats in it, and whether its worth hijacking.
Even more dependencies?? That sucks.
Beaker currently has zero dependencies. PyCrypto is only required for cookie-based sessions, though I think I’ll prolly add non-encrypted as well with a big caveat that the developer should be very aware the contents can be seen by an end-user.
Has VMAC undergone peer review? I can barely find anything about it online.