Increase the default factor for PBKDF2 based password hashing schemes

[mooreds]

Increase the default factor for PBKDF2 based password hashing schemes

Description

Currently, the FusionAuth default is 24,000 iterations for Salted PBKDF2 HMAC SHA-256, the default hash.

There is no recent NIST guidance on this.

OWASP recommends 600,000 iterations.

It would be worth while to review the current defaults and either document a recommended factor, or change our default to be similar to other industry standards.

The default value of 24,000 was set 8 or 9 years ago, and it is likely time for an update.

However, to note, we do provide a configuration to allow the FusionAuth admin to set a preferred factor so that the password factor can be updated over time (during login, password change, etc) to account for increasing CPU capacity. Regardless of our default value, it would be a good practice to periodically review the desired factor as CPU capacity increases.

To review this setting in your configuration, see Tenants > Edit > Passwords > Cryptographic hash settings > Factor. When Re-hash on login or change is enabled, the configured scheme and factor will be updated on next password touch (change, login, etc) for the user. Using this configuration allows you to upgrade the password hash complexity overtime.

Comparison

Here are some other hashing defaults:

Keycloak: 600,000 for pbkdf2-sha256

Auth0: 10 for bcrypt, doesn't use pbkdf2-sha256 as default hashing algorithm

Frontegg and Stytch do not publish their hash iterations (that I could find).

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

[robotdan]

Before we make this change we should do some performance testing to get an idea of how this affects login requests per second so we can update our EC2 / Compute guidance on scaling.

And ideally also understand if this change will have any negative impacts on normal runtime performance for "average" use cases. I doubt it.. but would be good to know. If the factor is linear for this algorithm, then in theory it will make the login 25 times slower if moving from 24,000 to 600,000.

[LucasPMorris]

It will have a significant performance impact if they have reject previous passwords enabled. #3063

[robotdan]

If we want to make this change, we should also review all production algorithms we ship. By production I mean hashing schemes we ship that are intended to be used in production and not simply provided for migration assistance.

• bcrypt - defaults to 12 (note that the bcrypt factor is logarithmic)
• salted-pbkdf2-hmac-sha256 - defaults to 24,000
• salted-pbkdf2-hmac-sha256-512 - defaults to 24,000
• salted-pbkdf2-hmac-sha512-512 - defaults to 24,000

My assumption is that we would only want to consider updating the PBKDF2 based schemes. We could also just update the documentation to indicate that a higher factor may be desired for these schemes.

Additional schemes we ship that are intended for migration assistance that do not likely need updating as they are intended to be modified to match a legacy hashing scheme and then immediately upgraded during next login or password change event.

• salted-md5 - defaults to 20,000
• salted-sha256 - defaults to 20,000
• salted-hmac-sha256 - defaults to 1
• phpass-md5 - defaults to 2,048
• phpass-sha512 - defaults to 32,768

Some preliminary testing shows that performing 100 hashing functions with a bcrypt factor of 12 has a CPU time roughly equivalent to using a PBKDF2 factor of 2,100,000.

So increasing the default to 600,000 will have a relatively small impact on performance per user. On my dev machine, increasing from 24,000 to 600,000 changes the average hash time from 10 ms to 92 ms. During a normal login this should not be perceptible to the end user.

Separately - when capacity planning for logins per second across your entire user population, this change could still be material and should be accounted for in planning, documentation, etc.

As it relates to rejecting previous passwords, and the performance impacts - as @LucasPMorris mentions - if you choose to enable reject previous passwords, and set this to something like 25, and each password uses the same scheme and factor, it could then increase the password change request from 250 ms to 2,300 ms. This would feel slower to the end user for sure, but even 2-3 seconds is not horrible - and this would only occur during a password change request.

Personally I think rejecting the last 25 passwords is not necessary, and enforcing the use of high quality passwords is a better security posture. See notes here: #3063 (comment)

The core intent of rejecting previous passwords is really to keep users from using a previously used password so users don't just use two passwords - alternating between the two. But once you get past rejecting one two, and if the user is taking advantage of a password manager, or generating high quality passwords in general, having FusionAuth remember so many passwords per user to try and keep them from being reused may be overkill.