13
$\begingroup$

(I realize this is yet another Argon2 "how do I configure" question, but the existing questions I've found don't really help. If I've missed one, happy to have this closed).

Deploying Argon2 (with the Argon2id variant) into a server environment to hash passwords and process site logins - the question we're grappling with is "how much memory to allocate". Now, I'm aware it's "as much as practically possible" but I haven't found any guidance on a lower limit (e.g., something that says something like "below 16MB it's not worth it").

This question suggests 32MB is good enough for most applications, and this one suggests '0.75 * (memory/users)' as a guideline, but not sure if this is reasonable?

Obviously, as iterations can be tuned upwards, we can maintain hardness in that dimension, but at what lower limit of memory would be considered "bad" or at least "not good" for Argon2? If this is pure to help avoid cache hits in a GPU then this would suggest allocations as low as 16MB may be okay, but am I missing something? If it's a case of "16MB okay, 32MB recommended, above 48MB there's nothing gained anything at the current state-of-the-art" that's also fine. I've seen people talk about 1GB allocations - this almost seems overkill?

Improve this question
$\endgroup$
7
  • $\begingroup$ This question may be hard to answer without knowing how much memory you have available on the server(s) that are computing the hashes. If you are running a single server with 4GB of RAM from out of your home you'll probably need a different answer than if you have a pool of 10 machines each with 64GB of RAM dedicated to password hashing. Also, the expected number of users you have may play a part as well. $\endgroup$
    – Ella Rose
    Sep 4, 2018 at 15:06
  • 2
    $\begingroup$ The standard recommendation is: Pick the memory usage as high as you can tolerate. $\endgroup$
    – SEJPM
    Sep 4, 2018 at 17:58
  • 1
    $\begingroup$ Also the smallest value the Argon2 paper (section 8) mentions is 256MB with the standard recommendations being 1GB-6GB "aka" as much as you can afford. $\endgroup$
    – SEJPM
    Sep 4, 2018 at 18:01
  • 1
    $\begingroup$ @SEJPM - I had seen this, but sec 8 though only talks about Argon2d and Argon2i - it doesn't reflect how the hybrid Argon2id affects this. Although yes, 250MB is the lowest value given in all the examples. Does this mean the suggestion of "32MB being reasonable" that I linked from another question should be treated with care? $\endgroup$
    – Chris J
    Sep 4, 2018 at 18:42
  • 3
    $\begingroup$ @Ella - I was hoping the advice would be rather generic, rather than needing to provide server config. Other than "it's not as strong", are there any practical attacks that are opened if 32MB is selected over 256MB (but with iterations increased so that computation time is roughly equivalent). $\endgroup$
    – Chris J
    Sep 4, 2018 at 18:49

2 Answers 2

Reset to default
4
$\begingroup$

An RFC for Argon2 has been published now, which provides several recommendations. Unfortunately, the situation is still not clear cut and seems unrealistic.

Their two generally recommended options are:

  1. If a uniformly safe option that is not tailored to your application or hardware is acceptable, select Argon2id with t=1 iteration, p=4 lanes, m=2^(21) (2 GiB of RAM), 128-bit salt, and 256-bit tag size.

  2. If much less memory is available, a uniformly safe option is Argon2id with t=3 iterations, p=4 lanes, m=2^(16) (64 MiB of RAM), 128-bit salt, and 256-bit tag size.

However, directly above that they state:

Argon2id is optimized for more realistic settings, where the adversary can possibly access the same machine, use its CPU, or mount cold-boot attacks. We suggest the following settings:

Backend server authentication, which takes 0.5 seconds on a 2 GHz CPU using 4 cores -- Argon2id with 8 lanes and 4 GiB of RAM.

Key derivation for hard-drive encryption, which takes 3 seconds on a 2 GHz CPU using 2 cores -- Argon2id with 4 lanes and 6 GiB of RAM.

Frontend server authentication, which takes 0.5 seconds on a 2 GHz CPU using 2 cores -- Argon2id with 4 lanes and 1 GiB of RAM.

Most of these memory suggestions sound unusably high to me. In contrast, the libsodium documentation says there's no 'insecure' memory size but obviously encourages more when possible.

For servers, you should probably opt for server relief to avoid DoS attacks. This involves both client-side and server-side hashing, potentially allowing slightly larger parameters on the client. However, the client-side parameters might have to be limited due to things like mobile devices.

I personally wouldn't go below 32 MiB and would consider 64 MiB a better minimum. However, it should be adjusted based on the hardware/clients for the best security. More memory is better than more iterations.

Many companies (e.g. online password managers) still seem to be avoiding Argon2 and sticking with PBKDF2 over efficiency concerns and JavaScript challenges.

Update - 09/01/2023

Steve Thomas, one of the Password Hashing Competition (PHC) judges, maintains a page with minimum settings for multiple password hashing algorithms, including Argon2. At the time of writing, this is more up-to-date than OWASP recommendations.

Also, in a server context, consider using bcrypt (ideally hmac-bcrypt) instead of Argon2. bcrypt is minimally cache-hard, so it offers better protection at shorter runtimes than Argon2, which is more suited to key derivation like scrypt.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ bscypt > argon? $\endgroup$
    – Paul Uszak
    Jan 9 at 22:45
  • 1
    $\begingroup$ @PaulUszak: IMHO, argon2 ≳ scrypt > bcrypt ≫ PBKDF2. Using PBKDF2 for key stretching in a new application without strong interoperability requirement is incompetence or/and bowing to the desire of authorities to be in a position to break the system if they see fit. $\endgroup$
    – fgrieu ♦
    Jan 10 at 14:10
  • 1
    $\begingroup$ @fgrieu Exactly what I was driving at :-) The linked conclusion(s) seem at odds with the majority opinion on this site. And bscrypt(best(sic)) with 256 KiB doesn't seem particularly memory hard. $\endgroup$
    – Paul Uszak
    Jan 10 at 16:00
  • 1
    $\begingroup$ @PaulUszak: while bscrypt is apparently a (rather new) thing, I don't know what it is, and it's not in my list. $\endgroup$
    – fgrieu ♦
    Jan 10 at 16:17
  • 1
    $\begingroup$ @samuel-lucas6: I don't yet clearly see the pros and cons of cache-hardness vs memory-hardness. That would make an interesting question. $\endgroup$
    – fgrieu ♦
    Jan 10 at 17:58
0
$\begingroup$

In the time since I asked this back in 2018, OWASP have published guidance on Argon2 at https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

At time of writing (Jan 2023), this says:

Argon2id should use one of the following configuration settings as a base minimum which includes the minimum memory size (m), the minimum number of iterations (t) and the degree of parallelism (p).

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

Both of these configuration settings are equivalent in the defense they provide. The only difference is a trade off between CPU and RAM usage.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ Steve Thomas' minimum settings are kept more up to date. As for a server environment, bcrypt is more suitable because it's minimally cache-hard and thus better at shorter runtimes than Argon2. Hopefully bscrypt will go places. $\endgroup$
    – samuel-lucas6
    Jan 9 at 21:00
  • 1
    $\begingroup$ @samuel-lucas6 Thanks for that link - useful to know. $\endgroup$
    – Chris J
    Jan 9 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.