Update: Password Storage Cheat Sheet - Update Argon2 to RFC 9106's recommended values

[f3ndot]

What is missing or needs to be updated?

Until quite recently with RFC 9106, the "best" or recommended parameter values for tuning Argon2 seemed to be arbitrarily chosen or change significantly over time. This OWASP cheatsheet is no different, and with many many places referring to it as the authority for using Argon2 over BCrypt, its imperative that the recommended parameter values within this doc adhere to the Argon2 authors' RFC 9106 that contain the recommended tuning values.

If there is still benefit to keeping the currently recommended values, explain their rationale and origin alongside the RFC recommended values.

How should this be resolved?

Recommend at least the two absolute recommended values in the RFC with the first being preferred:

1. High memory usage: t=1, p=4, m=2^21 (2 GiB)
2. Low memory usage: t=3, p=4, m=2^16 (64 MiB)

Then explain that, if the above two are unsuitable, how one should (must?) tune Argon2 to be sufficiently slow and memory intensive for their server or machine hardware. That is, select the highest t and m value that one can tolerate with p=4.

Outside of the RFC, it may be suitable to recommend what is "slow enough" for password hashing (500ms? 1000ms?).

[jmanico]

Our current values have been carefully selected, thanks to the extensive efforts of @Sc00bz.

As @Sc00bz is our knowledgeable expert in this area, I'll kindly ask him to respond to your comment.

You make a valid point that various standards have offered differing suggestions. It's indeed wise for us to continually evaluate our choices as new standards arise

[e4711s]

I think more information about how the values were chosen and how the recommended values for different algorithms relate to each other would be interesting.
For example when comparing the speed of the Spring Security BCryptPasswordEncoder with the recommended 10 iterations vs. Argon2PasswordEncoder with either of the recommended OWASP settings I noticed that Argon2id is consistently more than twice as fast.
If I were to migrate from BCrypt to Argon2 with those settings, would I merely get "equivalent" security? Or should I bump e.g. the iterations until Argon2 becomes as slow as the previously used BCrypt settings and then have the extra memory requirements on top of it as added benefit?

[jmanico]

Fast? Argon2id is not just about speed; it limits memory and how many threads can verify simultaneously. Bcrypt is just about speed. These are not to be compared directly! :) Different animals!

[Sc00bz]

The Argon2 RFC is a bad source for settings. I brought this up before it was published but didn't get a reply. I was going to ping the mailing list again, but it was pointless because it was publish as an RFC.

The main issue is that those two settings are not equivalent.

High memory usage: t=1, p=4, m=2^21 (2 GiB)
vs
Low memory usage: t=32, p=4, m=2^16 (64 MiB) (equivalent computations)
or
Low memory usage: t=22, p=4, m=2^16 (64 MiB) (equivalent memory bandwidth)

This doesn't even get into the fact that using those equivalent number of rounds doesn't make up for the lack of memory usage. So for those to be equivalent, the iterations would need to be increased by "(2048/64)^2" times. It might not need to be that high because m=64 MiB, p=4 is unlikely to limit the number of threads a GPU attacker can use. Also For some reason they say p=4 but only use 2 cores. As a defender you want to make p at most the number of cores you'll use. Otherwise you are giving the attacker an advantage. Also for a server you should use p=1 or use a queuing system to limit how many can run simultaneously.

Servers care about throughput so giving settings with p=1 is safer. See if you have settings that take 1000 ms with p=1 you'll think to lower the settings. If you have an 8 core CPU and you did p=8 then it might take 125 ms which is within reason, but you won't know it's a problem until after it's a problem.

If you're doing Argon2 on the client side then setting p to 2 for mobile or 4 for desktop is good.

---

These settings are based on limiting an attacker to <10 kH/s/"GPU". bcrypt cost 9, PBKDF2-HMAC-SHA512 with 210,000 iterations, Argon2 with m=12288 (12 MiB), t=3, p=1, and scrypt with N=2^14 (16 MiB), r=8, p=5 should all perform similarly for an attacker. So if one runs faster on your server then use that, but keep in mind that bcrypt cost "8.7" is equivalent to the Argon2 settings. Also the memory hard settings are based on theoretical max speed because there aren't any good public GPU implementations.

[kwwall]

@Sc00bz brings up a good point though...if the RFCs are wrong, then I think that the Password Storage Cheat Sheet should explicitly note that. Because, companies seem to prefer to use official de jure standards" (at least when they don't have to pay to access them!) rather than some unofficial statement, even if they are as reputable as OWASP.

Because of that, I think that Steve's argument above should definitely be noted.