CookieStore should use different keys for encryption and MAC
#5251

Comments

Please do not use the same key for both encryption and HMAC. Although a reuse of a key for different purposes is a bad practice in general, in some case the mistake might lead to a spectacular attack [1]. I know CookieStore uses HMAC, but why takes the risk? In addition, we want to make sure that if one of the schemes is broken, the key recovered by the attacker does not allow attacking the other.

We also want to avoid the the risk of somebody reusing the same key for unauthenticated encryption, i.e., Joe wants to encrypt his product ID, and he uses AES without HMAC, using config.secret_token as his key. In other words, he has introduced a padding oracle vulnerability [2], which can be used to decrypt cookies even though they use HMAC. This is the same mistake that ASP.NET made [3].

The best way to avoid this is to use a secure key derivation function, which is not very hard to implement, and derive separate keys for different purposes from config.secret_token. Something as simple as

key = SHA256(config.secret_token + "PURPOSE")

would be more secure than the current approach.

I'm willing to help either implement the fix for this issue or review somebody else's code.