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

[Alex Vandiver]

On Tue, 2013-09-03 at 00:03 -0700, Reed Loden wrote:
> Keep in mind that using bcrypt alone creates a limit on the maximum
> length of passwords[0]. I recommend you hash the password itself (using
> SHA-256 or even HMAC-SHA-256 with a pepper) and then pass the SHA hash
> to bcrypt as the 'password' input. That way, your users can have
> passwords of whatever length they want, and you're not dropping bits on
> the floor.

Thanks for the heads-up on this; we were unaware of the maximum key
length on the bcrypt input.  We'll push a change to sha256 the input
prior to passing it to bcrypt.

> 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.
  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.

> It would also be nice to have the cost be a setting somewhere and have
> it "upgrade" a person's password hash on log in if their old hash used a
> different cost than what the current default is (since a bcrypt hash
> will include the cost factor that was used to create it originally).

Incrementally adjusting the cost factor is indeed planned, but the
functionality to do so will be rolled into the first time we need to
adjust the number of rounds.

> As a side note, have you looked at scrypt[2] yet? It's still fairly new,
> but it adds a memory requirement to hash generation, making it even
> less susceptible to offline brute-force attacks.

We're aware of it, but didn't feel that it was mature enough to move to
using it, nor that its use was particularly strongly indicated.

 - Alex

[0] http://security.stackexchange.com/questions/3959/#3993