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?
On Thursday, January 22, 2015 at 10:45:00 AM UTC+11, Andrew Kaspick wrote:
> 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, <jsma...@gmail.com <javascript:>> 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-co...@googlegroups.com <javascript:>.
>> To post to this group, send email to rubyonra...@googlegroups.com
>> <javascript:>.
>> 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.
