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. On Tue Jan 20 2015 at 7:12:03 PM <jsmall...@gmail.com> wrote: > 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. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
