I am trying to figure out the best parameters for Argon2 for password hashing.

I have read the RFC and the recommendations they put into it. So I follow up on the recommendation on the paper depending on my target machine.

The thing is that one single call fits perfectly into the desired time. However, they never mention several calls at the same time.

For example. I have a server with 8 CPU cores and 32GB RAM. Then I configure an Argon2id with: 16 lanes, 1 iteration, and 128MiB memory.

I call it once. Perfect! I got an execution time of ˜50ms. Now I simulate several calls at the same time. Execution time increases a lot. For 20 parallel calls, execution time goes up to ˜500ms.

I can tune the algorithm to fit with the average traffic on the server to fit the desired time, but every time I will have a peak, performances will be deteriorated. And this also means lowering the values which means cheaper to attack.

Which is the best way to proceed?

  • $\begingroup$ Remember, the iteration is to reduce the attack time and memory is reduce the parallelization. Yo need more iterations as 1000000. $\endgroup$
    – kelalaka
    Commented Jan 29, 2019 at 18:05
  • 6
    $\begingroup$ @kelalaka I think 1,000,000 iterations for Argon2 is very excessive. For 128 MiB, that would require performing more than a hundred terabytes of memory access. Also, for Argon2, iterations is primarily not to increase processing time but to reduce the TMTO ratio the attacker can pull off. More iterations means less flexibility for the attacker, no matter how long each iteration takes. $\endgroup$
    – forest
    Commented Jan 30, 2019 at 6:05
  • 3
    $\begingroup$ @kelalaka Argon2 doesn't work like PBKDF2. It has two cost parameters. The "time" parameter is the number of passes made over the memory buffer. (This is why increasing the memory parameter and leaving the pass count alone increases run time.) There is no iteration-count parameter of the sort that PBKDF2 has. If you use enough memory then the number of passes can be fairly small. As low as 1 for Argon2d and 3 (or maybe more) for Argon2i. Using gigabytes of memory with a single digit number of passes is preferable to using low memory with many many passes. $\endgroup$ Commented Aug 14, 2019 at 16:33
  • $\begingroup$ What do you mean by 500ms execution time? That's not the total wall clock time between the first request and the last hash to finish. I would expect that to be at least 20 times the single hash time if you had 20 parallel hashes. (With that many lanes it should be.) How do you measure run time? $\endgroup$ Commented Aug 15, 2019 at 0:34

1 Answer 1


Even relatively modest values for the memory and time parameters will make it very hard for an attacker to do an offline brute-force attack on your users' passwords, since they have to try so many passwords to find one.

So you should pick values that allow your servers to perform acceptably, even given the maximum rate of login attempts that you permit. Denial-of-service (DOS) attacks are a risk, so you need to use appropriate methods to limit the number of simultaneous login attempts, and throttle repeated attempts before they overwhelm your memory and CPU.

See advice on Blocking Brute Force Attacks | OWASP via CAPCHAS, secondary delays, device cookies, unpredictable behavior, lockouts by IP address, etc. See also more generic advice on defending against Denial of Service.


Your Answer

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

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