GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
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 . 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 , which can be used to decrypt cookies even though they use HMAC. This is the same mistake that ASP.NET made .
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.
MRI's OpenSSL module has PKCS5.pbkdf2_hmac and PKCS5.pbkdf2_hmac_sha1, which are secure key derivation functions that you can use.
What encryption? As far as I'm aware CookieStore only signs the data and doesn't encrypt it.
There was a discussion on encrypted store here: #3955 and implementation here: #5034. It seems that it uses only one secret key, so it's a good idea to address that before it's merged.