pregnenoloneOct 15

Evaluating Argon2 adoption and effectiveness in real-world software

https://arxiv.org/abs/2504.17121

Evaluating Argon2 Adoption and Effectiveness in Real-World Software

Modern password hashing remains a critical defense against credential cracking, yet the transition from theoretically secure algorithms to robust real-world implementations remains fraught with challenges. This paper presents a dual analysis of Argon2, the Password Hashing Competition winner, combining attack simulations quantifying how parameter configurations impact guessing costs under realistic budgets, with the first large-scale empirical study of Argon2 adoption across public GitHub software repositories. Our economic model, validated against cryptocurrency mining benchmarks, demonstrates that OWASP's recommended 46 MiB configuration reduces compromise rates by 42.5% compared to SHA-256 at \$1/account attack budgets for strong user passwords. However, memory-hardness exhibits diminishing returns as increasing allocations to RFC 9106's 2048 MiB provides just 23.3% (\$1) and 17.7% (\$20) additional protection despite 44.5 times greater memory demands. Crucially, both configurations fail to mitigate risks from weak passwords, with 96.9-99.8% compromise rates for RockYou-like credentials regardless of algorithm choice. Our repository analysis shows accelerating Argon2 adoption, yet weak configuration practices: 46.6% of deployments use weaker-than-OWASP parameters. Surprisingly, sensitive applications (password managers, encryption tools) show no stronger configurations than general software. Our findings highlight that a secure algorithm alone cannot ensure security, effective parameter guidance and developer education remain essential for realizing Argon2's theoretical advantages.

arXiv.org
Show threadpalantirdOct 22

> ... developer education remain essential for realizing Argon2's theoretical advantages.

> 46.6% of deployments use weaker-than-OWASP parameters.

Sounds like a job for better default parameter values.
I'm willing to bet most startups just install the default argon2 (or password hashing) library in their language of choice and don't jump head-first into the rabbithole of fine-tuning argon2 parameters unless a contract or certification depend on it.

Show threadswiftcoderOct 22

The documentation on this is... uh... intimidating? I come away from this with the sense that I need to learn a whole lot about cryptography to make a good decision here:

https://argon2-cffi.readthedocs.io/en/stable/parameters.html

Choosing Parameters - argon2-cffi 25.1.0 documentation

Show threadluizfelbertiOct 22

Do not reference these kinds of docs whenever you need practical, actionable advice. They serve their purpose, but are for a completely different kind of audience.

For anyone perusing this thread, your first resource for this kind of security advice should probably be the OWASP cheatsheets which is a living set of documents that packages current practice into direct recommendations for implementers.

Here's what it says about tuning Argon2:

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

Password Storage - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

Show threadtptacek
It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.
Oct 22 at 1:11pmWeb
Show threadlinsomniacOct 22

Do you have a better recommendation?

I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.

Show threadrubendevOct 22
The OWASP ASVS appendix on Cryptography is one of the best and concise resources I know for this kind of thing: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Append...
ASVS/5.0/en/0x92-Appendix-C_Cryptography.md at master · OWASP/ASVS

Application Security Verification Standard. Contribute to OWASP/ASVS development by creating an account on GitHub.

GitHub
Show threadakerl_Oct 22

I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it.

If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.

Show threadrubendevOct 22

Also, I gave the link to the appendix because there was a specific question about Argon2 parameters. For general developer audiences, they need to look at the standard itself which is a lot more high level about how to properly implement cryptography in software:
https://github.com/OWASP/ASVS/blob/master/5.0/en/0x20-V11-Cr...

For the most common use-cases of cryptography like authentication and secure communication there is more specific, but still high level guidance that is useful for developers as well:

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x21-V12-Se...

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x18-V9-Sel...

- https://github.com/OWASP/ASVS/blob/master/5.0/en/0x15-V6-Aut...

Show threadtptacekOct 23
This standard is bad. People should avoid it. For example: 11.2.2 (cryptographic agility) is an anti-pattern in modern cryptographic engineering.
Show threadtptacekOct 22

This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator.

This is a mess, and I would actively steer people away from it.

Show threadrubendevOct 22

Yes it’s an audit checklist for when you need to know specifically what to use and with which parameters.

It’s unfortunate if there are mistakes in there. The people at OWASP would be very happy to receive feedback on their GitHub I’m sure.

Show threadtptacekOct 22
It's a bad audit checklist! If OWASP volunteers can't do a good one, they should just not do one at all. It's fine for them not to cover things that are outside their expertise.
Show threadrubendevOct 22
Which one would you recommend instead? Referring dev teams to NIST standards or the like doesn’t work well in my experience.
Show threadtptacekOct 22
There doesn't always have to be a resource. Sometimes no resource is better than a faulty one. Cryptography is one of those cases.