[rt-devel] [Rt-commit] rt branch, 4.2/bcrypt-cost, created. rt-4.2.10-238-g0c5d384

[Reed Loden]

Why not use a bcrypt cost of 12, which is what a lot of bcrypt libraries
are using for a default nowadays?

There's even some helpful math and data at
https://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
to show how 12 (at the least) may be a good *minimum* cost.

Also, I would look into scrypt. It's been around long enough that it's
starting to prove it's worth. bcrypt really only worries about CPU cycles,
while scrypt takes CPU and RAM into account.

~reed

On Mon, May 4, 2015 at 1:52 PM, Alex Vandiver <alexmv at bestpractical.com>
wrote:

> The branch, 4.2/bcrypt-cost has been created
>         at  0c5d3842926dcf05fe227d8f8d57f41e517c09b2 (commit)
>
> - Log -----------------------------------------------------------------
> commit 0c5d3842926dcf05fe227d8f8d57f41e517c09b2
> Author: Alex Vandiver <alexmv at bestpractical.com>
> Date:   Mon May 4 16:42:03 2015 -0400
>
>     Increase the bcrypt cost by a factor of two
>
>     The bcrypt key derivation function contains a tuning parameter, the
>     number of "rounds" to run, which allows the same algorithm to have
>     increased computational cost, to prevent brute force attacks, as
>     computers grow faster.
>
>     Moore's Law estimates a doubling in the number of transistors every 18
>     months, which is, in broad strokes, also similar to a doubling in
>     computational power every 18 months.  RT introduced the use of bcrypt
> in
>     September 2013; as such, the complexity of key derivation is now due to
>     be doubled.  This is done by increasing the number of rounds by one.
>
>     Old passwords (with lower costs) will still work, but will be upgraded
>     as soon as a user logs in.
>
> diff --git a/etc/RT_Config.pm.in b/etc/RT_Config.pm.in
> index 7ece63f..a519802 100644
> --- a/etc/RT_Config.pm.in
> +++ b/etc/RT_Config.pm.in
> @@ -2071,7 +2071,7 @@ higher numbers denoting greater effort.
>
>  =cut
>
> -Set($BcryptCost, 10);
> +Set($BcryptCost, 11);
>
>  =back
>
> diff --git a/t/api/password-types.t b/t/api/password-types.t
> index 9eeded4..3278b48 100644
> --- a/t/api/password-types.t
> +++ b/t/api/password-types.t
> @@ -16,11 +16,12 @@ ok($root->IsPassword("password"));
>  is($root->__Value("Password"), $old, "Unchanged after password check");
>
>  # bcrypt (smaller number of rounds)
> +my $rounds = RT->Config->Get("BcryptCost");
>  my $salt = Crypt::Eksblowfish::Bcrypt::en_base64("a"x16);
>  $root->_Set( Field => "Password", Value =>
> RT::User->_GeneratePassword_bcrypt("smaller", 6, $salt) );
>  like($root->__Value("Password"), qr/^\!$default\!06\!/, "Stored with a
> smaller number of rounds");
>  ok($root->IsPassword("smaller"), "Smaller number of bcrypt rounds works");
> -like($root->__Value("Password"), qr/^\!$default\!10\!/, "And is now
> upgraded to salted $default");
> +like($root->__Value("Password"), qr/^\!$default\!$rounds\!/, "And is now
> upgraded to $rounds rounds");
>
>  # Salted SHA-512, one round
>  $root->_Set( Field => "Password", Value =>
> RT::User->_GeneratePassword_sha512("other", "salt") );
>
> -----------------------------------------------------------------------
> _______________________________________________
> rt-commit mailing list
> rt-commit at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-commit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-devel/attachments/20150505/81fe5f08/attachment.html>