Update PasswordEncoder Minimums

[jzheaux]

Based on #10447 (comment), Argon2PasswordEncoder, ScryptPasswordEncoder, and Pbkdf2PasswordEncoder should have their minimums updated.

Please also see gh-7411 gh-4788

[larsgrefer]

see also #7411 (comment)

[ioanadinuit]

Hi, did someone take this issue? I would like to contribuite.

[jzheaux]

@ioanadinuit, thanks for volunteering! The ticket is yours.

One thing we need to keep in mind is what will happen to folks when they upgrade to Spring Security 6.

Ideally, existing hashes will still work which is not as simple with Pbkdf2PasswordEncoder, which does not support upgrading. It may be necessary to implement #9833 before changing PBKDF2 default settings.

[jzheaux]

@Sc00bz, I'd prefer to go off of the recommendations on the OWASP cheat sheet. They vary just slightly from your recommendations in your comment. Do you have any concerns with going with the recommendations from the cheat sheet?

[rwinch]

Please also see gh-7411

[Sc00bz]

@jzheaux That OWASP cheat sheet is based on my recommendations.

The four changes I suggested to this project's defaults:

---

Argon2's setting are m=4 MiB, t=3, p=1 either set it to 10 MiB or 7 iterations.

OWASP cheat sheet has for Argon2:

m=37 MiB, t=1, p=1
m=15 MiB, t=2, p=1

The curator trimmed the list at the first two. Numbers came from these formulas:
Argon2i: m≥74219/(3*t-1)*α, t≥3, p=1
Argon2{id,d}: m≥74219/(3*t-1)*α, t≥1, p=1

m≥36.24 MiB, t=1, p=1
m≥14.50 MiB, t=2, p=1
m≥9.06 MiB, t=3, p=1 ****
...
m≥4.26 MiB, t=6, p=1
m≥3.62 MiB, t=7, p=1 ****

---

scrypt's settings are N=2^14, r=8, p=1 (16 MiB) either set N to 2^16 (64 MiB) or p to 4.

OWASP cheat sheet has for scrypt:

N=2^16 (64 MiB), r=8 (1024 bytes), p=1 ****
N=2^15 (32 MiB), r=8 (1024 bytes), p=2
N=2^14 (16 MiB), r=8 (1024 bytes), p=4 ****
...

---

PBKDF2 settings are SHA1, 185k iterations, 256 bits of output. This should be changed to SHA512 and 120k iterations.

OWASP cheat sheet has for PBKDF2:

PBKDF2-HMAC-SHA1: 720,000 iterations
PBKDF2-HMAC-SHA256: 310,000 iterations
PBKDF2-HMAC-SHA512: 120,000 iterations ****

Note using SHA512 is better than the others if the one calculating it has a 64 bit CPU. SHA1 and SHA256 are better if the one calculating it has CPU instructions for them.

---

bcrypt setting is cost 10. Cost 9 is actually quite strong and is similar to PBKDF2-SHA512 with 230k iterations in strength.

It was a hard fought battle to get the recommended down to cost 10. Note cost "8.1" is the minimum for bcrypt, but it's an integer so 9.

---

P.S. A new GPU came out since those recommendations. It's ~3% faster compute and 20% more memory bandwidth.

Argon2 m=4 MiB, t=7, p=1 is now m=4 MiB, t=8, p=1.
Argon2 m=10 MiB, t=3, p=1 is now m=11 MiB, t=3, p=1.
scrypt N=2^16 (64 MiB), r=8 (1024 bytes), p=1 is now N=2^17 (128 MiB), r=8 (1024 bytes), p=1
scrypt N=2^14 (16 MiB), r=8 (1024 bytes), p=4 is now N=2^14 (16 MiB), r=8 (1024 bytes), p=5
PBKDF2-HMAC-SHA512 120,000 iterations is now 130,000 iterations.
bcrypt is still cost 9.

Note this is how minimums work. Normally every year a new GPU comes out that's 20%+ faster. Last few years have been abnormal. If I were to guess, I'd guess there's going to be a jump in minimums around October.

[rwinch]

Please see gh-4788

[rwinch]

@Sc00bz Thanks for the updated numbers. The trouble is that we don't know what hardware users are leveraging to run their servers and minimums are a tradeoff. The attackers will always have better optimized hardware for cracking than the defenders will for validating passwords because the defenders need to do more than passwords and it is unlikely they will leverage GPUs. It's all about trade offs. Using a workfactor that is too large will potentially cause a DoS for the application servers.

The best we can do is follow the guidance for now and ensure we can support upgrading in the future. This is why we are also looking to implement gh-9833

[Sc00bz]

... the defenders need to do more than passwords and it is unlikely they will leverage GPUs.

Argon2, bcrypt, PBKDF2, and scrypt can't run on a GPU for the defender. Well they could but it would be very slow. Minimums are set to prevent attackers from getting >10 kH/s/GPU.

Using a workfactor that is too large will potentially cause a DoS for the application servers.

Note bcrypt cost 9 is super fast because it is a good algorithm. PBKDF2-HMAC-SHA512 with 130,000 iterations is slow because PBKDF2 is a bad algorithm. If bad algorithms are causing DoS issues, then you should deprecate those algorithms.