On Mon, Aug 20, 2012 at 5:54 PM, Greg Sabino Mullane <g...@turnstep.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
