For Rails 5, could you potentially make SHA-256 the default for new apps
and opt-in for existing apps?
On Wed, Jan 21, 2015 at 5:52 PM, <jsmall...@gmail.com> wrote:
> 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.
>
> On a related note, why is the CookieStore passed through Base64 encode
> twice? Look at a small piece of parsing code I wrote:
>
> 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.
>
> On Wednesday, January 21, 2015 at 6:36:51 AM UTC+11, Michael Koziarski
> wrote:
>
>> 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 <jsma...@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-co...@googlegroups.com.
>>> To post to this group, send email to rubyonra...@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.
>
--
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.
