Hi,
I note that Cookiestore signs its data using SHA-1.
I have found this issue regarding this: https://github.com/rails/rails/pull/11677
There it was noted that documentation was updated from SHA512, which would appear to have been considered at one time, to using SHA1 “for compatibility”. SHA-1 is considered a deprecated cryptographic hash. The deprecation of support for SHA-1 certificates by Google in the Chrome browser is an example of proactive deprecation of obsolete algorithms that is generally well accepted by the community. The long term lifespan of a Cookiestore session cookie, coupled with the sensitivity of the session data often stored within it should be considered to amplify the threat.
I was wondering what “compatibility” issues would be present in changing the default hash to SHA-256 for an upcoming rails 5. It’s been supported in OpenSSL for a very long time, which is in turn used to generate this hash. The documentation update was over a year ago, and that only documented an earlier configuration change which I don’t believe to reflect current security practice.
Moreover, that particular PR discusses this as not being configurable. I’ve spent some time trying to get a gem to override it without much success.
Any assistance on towards making this a default, or on how it could be turned into a gem would be appreciated.
Switching to another hashing function for Rails 5 would definitely be possible. The compatibility concerns are twofold:
-
Old hashes are no longer valid, so you sign everyone out the day you do that deploy
-
Various old rubies on old OSes ship with old OpenSSL which didn’t support it.
That second concern is well and truly gone these days so there’s no reason to worry about it. However the first concern remains. You’d have to offer a transitional system where it accepted sha1 hashes and returned sha256 ones. You’d also need to think carefully about the defaults because if you accept the sha1 hashes forever you’re never actually closing the theoretical issues. It’s not particularly difficult just requires time and effort.
Finally, the issues you’re raising around sha1 don’t necessarily apply when used in an HMAC as it is here. We should definitely upgrade over time, but it’s not as pressing as the TLS certs case.
Thanks for this response.
I guess that’s a question of how big a jump Rails 5 is meant to be. I certainly wouldn’t propose this on a minor jump, but I’d figured if you were rolling from Rails 4 to Rails 5 you could probably deal with sign outs. I understand the reasons it isn’t hugely pressing, but again, if you were to “upgrade over time”, I’d like to consider a major version jump as the time to do it. Alternatively, there’s room to simply look at the length of a presented hash to check for backward compatibility hashes.
str, sign = unescaped_cookie.split(/–/)
Hex encoded HMAC
puts 'HMAC as per cookie validator: ’ + sign
str2 = str.unpack(‘m’).join
cipher, iv = str2.split(/–/)
cipher = c.unpack(‘m’).join
iv = iv.unpack(‘m’).join
What this says is that the Cookiestore is basically formatted as: B64(B64(iv)–B64(cipher))–hex(HMAC)
I get the feeling that could be much more efficient, both in performance, and the size of the generated cookies, by skipping that outer encode.
For Rails 5, could you potentially make SHA-256 the default for new apps and opt-in for existing apps?
Hi,
That would be in line with what I would suggest to be a good idea.
I’d similarly suggest this redundant Base64 process could be configured that way unless anyone can point to a reason it’s actually needed?
