couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: JavaScript bcrypt (was Re: authentication cleanup)
Date Wed, 27 Jan 2010 16:12:28 GMT

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


Mime
View raw message