On 12/19/07, tekwiz <[EMAIL PROTECTED]> wrote: > > After looking at the controversy, delving into my security textbook, > and reading some articles on hashing, I would like to recommend some > tweaks to the CookieSesson defaults and the new 'rake secret'. > > 1) Change the default hash used in the cookies to SHA256 as a hole > was semi-recently found in SHA1. >
I don't mind either way, another few bytes couldn't hurt if the algorithm is readily available. But which attack on SHA1 are you referring to? Any 'feasible' attack I've seen involves finding collisions, i.e. one person creating two messages with the same digest, which is of no significance here. Finding a message M1 where, for a given message M0, SHA1(M1) = SHA1(M0), requires an effort of ~2**106 (Bruce Schneier, Feb 2005 [1]). Please cite some sources, there's already been plenty of FUD on this topic. > 2) Make 'rake secret' use the lengthier SHA512 hash and output the > secret key in base64, or better yet, in a binary string. The 30 > character length requirement will require multiple hashes to be > generated; however, it will add a significant amount of entropy to > every character. (The limited character set in a hex-characters-only > key may lead to a differential cryptanalysis -- I'm no crypto-expert, > so if someone else knows different, please ease my mind) Encoding doesn't matter, we just need a secret with enough significant bits. If you're saying that the requirement should be raised to account for people using hex-only (which they might, as that's what the generated string does), you may have a point. > OR > 3) Make 'rake secret' use OpenSSL to generate the secret key. AFAIK Rails' SecretKeyGenerator already does use OpenSSL or other strong platform-specific crypto libraries if available. "rake secret", at least here on rails 2.0.2, outputs a 128-char hex string, that's 512 bits. I'm not in a position to comment on whether that's strong or weak. > 4) Add, at least an option, to hash the IP address of the user into > the cookie's hash. This should prevent against replay attacks > automatically without the application developer having to write in > this check. As mentioned by others, this is very likely to break things. Crypto is hard, and the more people who look at Rails' implementation, the better. There's been a lot of random noise and FUD on this topic, but if you know what you're doing I'm sure more input and contributions are welcome. Regards, Isak [1] <http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
