From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sha1, sha2 functions into core? |
Date: | 2012-08-21 18:58:30 |
Message-ID: | CAHyXU0z9ZAGAfc-0hTOAT0YycgoNWKVV+FUO3KNaeUPwPAy6-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 20, 2012 at 5:54 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>> 3) use a purposefully slow hashing function like bcrypt.
>>
>> but I disagree: I don't like any scheme that encourages use of low
>> entropy passwords.
>
> Perhaps off-topic, but how to do you figure that?
Yeah -- bcrypt's main claim to fame is that it's slow. I *lot* of
people argue your'e better off with a slow hash and that's reasonable
but I just don't like the speed/convenience tradeoff. I suppose I'm
impatient. My take on this is that relying on hash speed to protect
you if the attacker has the hash, the salt, and knows the algorithm is
pretty weak sauce. At best it lowers the entropy requirements
somewhat: an 80 bit entropy password is not brute forcible no matter
how many server farmed GPUs you have. The mechanics of how the hash
is calculated (see Joe C's excellent comments upthread) are much more
important considerations than algorithm choice.
If you have high security requirements and your users refuse to use
high entropy passwords, I think you're better off going 2-factor then
hoisting slowness on everything that needs to authenticate.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-21 20:03:12 | Re: 9.2RC1 wraps this Thursday ... |
Previous Message | Stephen Frost | 2012-08-21 18:23:52 | Re: Slow tab completion w/ lots of tables |