couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: JavaScript bcrypt (was Re: authentication cleanup)
Date Wed, 27 Jan 2010 16:26:39 GMT
On Wed, Jan 27, 2010 at 8:12 AM, Jan Lehnardt <> wrote:
> 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
>  "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.

More secure without more dependencies," which works for me.

Can you point to other people using HMAC in this capacity? Or other
prior art. Don't invent your own crypto systems, that sort of thing.


Chris Anderson

View raw message