On 27 Jan 2010, at 07:27, Brian Candler wrote: > On Wed, Jan 27, 2010 at 06:33:12AM -0800, Jan Lehnardt wrote: >> I'm not a crypto expert, but it seems we can get away with sha1 if we use >> HMAC instead of just hashing + salting: > > Errm, do you mean HMAC with a fixed server-side secret? > > This means that if you replicate user records between servers, you must have > the same secret on both boxes. This could be either a problem or a benefit, > depending on how you look at it. > > But once your system has registered its first user, it will be impossible to > change to a different secret; in 10 years' time you'll have to be using the > same one. Over time, the chances increase that the secret will leak somehow > (admin staff members leaving, for instance), at which point you are no > better off than a regular hash. > > If you mean "use HMAC to mix in the salt", then that's an unnecessary > application of a HMAC. The salt isn't secret, it's public.
Quoting http://en.wikipedia.org/wiki/HMAC: "The values of ipad and opad are not critical to the security of the algorithm" If you mean these by "secret", otherwise I don't follow. I see HMAC as a hashing algorithm-agnostic way to hash secrets. SHA1 isn't meant to hash passwords and the article I quoted outlines potential attacks even with salting like we do now. HMAC allows us to use SHA1 without being subject to these attacks. My reasoning here is that a SHA implementation is easier to come by universally than a bcrypt one. Cheers Jan --
