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
--
|