[SAI_Peregrinus]

It's not memory-hard. That makes it much, much faster on GPUs than CPUs, which tends to mean it's much faster for attackers than legitimate users. It's also likely vunlerable to side-channel attacks, since nothing in its design tries to resist those. It's not broken by any means, and still vastly better than just a salted cryptographic hash, but it's not as good as Argon2id.

[alserio]

If I may ask a question: how would I use a memory hardened algorithm on a server if the server ram can't scale infinitely? It seems to me that a few concurrent user logins would effectively DOS the server for any reasonable configuration of argon2

[SAI_Peregrinus]

You don't actually need it to use that much RAM. It's more about memory bandwidth. An attacker can increase the memory bandwidth by using block RAM like in an FPGA or on-die RAM in an ASIC, but both of those are far more expensive than discrete DDR DRAM modules. So with appropriate memory usage (enough to saturate the cache lines) it can be cheap enough for the server to run yet still more expensive to build an ASIC platform for. Of course an ASIC can use DDR as well, but then it's stuck with the same memory bandwidth as the DDR module and gains no particular advantage.

Argon2id with t=3, m=92MiB, p=1 should be slower than bcrypt with cost 12 on most modern GPUs. That's not actually all that much memory, you can handle quite a few concurrent logins on a server with those settings. 10 concurrent logins per GiB of RAM dedicated to the task. And it should only DOS the login process, so it might make taking out your auth process (or server) easier but won't necessarily harm any other part of the site.

[alserio]

Thank you. I find a GiB for 10 concurrent logins still a bit too much for some use cases but you have given me a better understanding of the trade-off involved.