Rt branch, 4.2/bcrypt-cost, created. rt-4.2.10-238-g0c5d384

RT Developers
1

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

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.

~reedOn Mon, May 4, 2015 at 1:52 PM, Alex Vandiver alexmv@bestpractical.com wrote:

The branch, 4.2/bcrypt-cost has been created
at 0c5d3842926dcf05fe227d8f8d57f41e517c09b2 (commit)

  • Log -----------------------------------------------------------------
    commit 0c5d3842926dcf05fe227d8f8d57f41e517c09b2
    Author: Alex Vandiver alexmv@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@lists.bestpractical.com
rt-commit Info Page

2

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

Hm. Which ones?

There’s even some helpful math and data at
Recommended # of rounds for bcrypt - Information Security Stack Exchange
to show how 12 (at the least) may be a good minimum cost.

As cryptography - Recommended # of iterations when using PBKDF2-SHA256? - Information Security Stack Exchange notes:

“You should use the maximum number of rounds which is tolerable,
performance-wise, in your application.”

RT is often installed on servers which are not top-of-the-line
hardware, which is why a not-terribly-aggressive default value was
chosen when RT began using bcrypt. This commit is merely maintaining
that choice.

Increasing it to 12 or higher isn’t inherently unreasonable, but must
be balanced against the fact that most users expect their webservers to
respond to login requests in less the 5s that older hardware might
begin taking.

It’s possible that the Most Right solution is for RT to benchmark at
“configure” time and set a default accordingly. This would ensure that
it was re-evaluated during every upgrade, as well as when re-installed
on newer hardware.

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.

We won’t be switching the key derivation function during a stable
series unless a strong vulnerability is found in bcrypt. scrypt is
something to keep in mind as a possible option for 4.4, however.

  • Alex