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

On Tue, 5 May 2015 00:02:55 -0700 Reed Loden <[email protected]> wrote:
> 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
> https://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
> to show how 12 (at the least) may be a good *minimum* cost.

As http://security.stackexchange.com/a/3993/11197 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