[rt-devel] [Rt-commit] rt branch, 4.2/bcrypt-passwords, created. rt-4.1.19-32-g07ac7c5

[Reed Loden]

On Tue, 03 Sep 2013 15:31:23 -0400
Alex Vandiver <alexmv at bestpractical.com> wrote:

> > Also, bcrypt cost of 8 is not great at all (no idea why that is a
> > default, as it's pretty terrible[1]). I recommend you use at least 12.
> 
> There is no one correct number; the speed of the server, the persistence
> of the attacker, and the expected entropy of the passwords must be
> factored into account -- see [0] for a good discussion of this.  In
> testing, a cost factor of 8 on modest hardware yields a time of ~26ms
> per hash, which is above the recommended hashing time.  A cost factor of
> 12 on modest hardware takes nearly half a second to hash, which is a
> notable time delay upon login, and would visibly impact responsiveness
> of the application.

Note that Crypt::Eksblowfish::Bcrypt doesn't actually use 8 by
default (just mentions it in the POD example). I did a quick check to
see what other major languages were using (as their actual defaults),
and they use at least 10 for the cost.

bcrypt-ruby - 10
(http://bcrypt-ruby.rubyforge.org/classes/BCrypt/Engine.html)
py-bcrypt - 12 (http://www.mindrot.org/projects/py-bcrypt/)
PHP password_hash() - 10 (http://php.net/password_hash)
bcrypt.go - 10
(https://code.google.com/p/go/source/browse/bcrypt/bcrypt.go?repo=crypto)
jBCrypt - 10 (http://www.mindrot.org/projects/jBCrypt/)
BCrypt.Net - 10
(https://bcrypt.codeplex.com/SourceControl/latest#BCrypt.Net/BCrypt.cs)
JFBCrypt - 10
(https://github.com/jayfuerstenberg/JFCommon/blob/master/JFBCrypt.m)

As such, I think it would be prudent to at least use 10, especially if
you feel that 12 is too slow (though, I don't think half a second on
login is that much to worry with, imho). This is especially true if you
don't plan on updating the cost for at least 2 years.

>   No cost factor will cover for low-entropy passwords, which in our
> experience are unfortunately common in many deployments.  A cost factor
> of 8 is thus a compromise.  You are of course welcome to increase the
> cost factor locally if you deem it appropriate for your data, and your
> hardware is capable of bearing the computational cost.  We expect to
> raise the default in core RT every ~two years to follow hardware trends.

Considering it's hardcoded, changing it locally is not easy. If it was
a constant somewhere, that might be more feasible.

~reed