Improvements!

[ccutrer]

• don't bother encrypting the IV (?!)
  • use the same encryption key for the encryption as for the HMAC (easy to configure, since it's the same as for normal CookieStore)
  • compress the session before encrypting it (optional, will skip compression if it actually makes it larger)
  • use AES 128 CBC (AES 256 is actually weaker, due to a known attack on it), which also reduces the cookie size due to a smaller IV and less padding
  • use URI-safe base64 encoding to not waste space percent-encoding characters in the cookie
  • use . as the separator between cookie fields (instead of -, which is now a part of the base64 encoding)
  • if :expire_after is provided, add a timestamp to the cookie that's included in the HMAC to allow for secure expiration of cookies (preventing session replay attacks after the expiration of the cookie)
  • don't re-set the cookie on every request if the session hasn't changed (unless :expire_after is in use, in which case do it every 5 minutes by default in order to refresh the timestamp)

[FooBarWidget]

Very nice! But why not encrypt the IV? Is it supposed to be public information?

I'm opposed to removing the "It is prone to session replay attacks" sentence from the README. You are less prone now but not completely invulnerable. Attackers can still replay sessions within the timeout period.

[ccutrer]

Because it's a waste of CPU cycles, adds unnecessary complexity, and does not add any "real" security (an IV is completely random data anyway; encrypting the randomness doesn't make it any more random, nor increase the security of bruteforcing the encrypted data): http://stackoverflow.com/questions/6167114/protect-encrypt-initialization-vector

I'll adjust the readme re: session replay attacks.