Evaluating Argon2 Adoption and Effectiveness in Real-World Software

Posted3 months agoActive3 months ago

pregnenolone

32 points

32 comments

arxiv.orgTechstory

calmneutral

Debate

40/100

Password HashingArgon2Cryptography

Key topics

Password Hashing

Argon2

Cryptography

A research paper evaluates the adoption and effectiveness of Argon2, a password hashing algorithm, in real-world software, sparking discussion on its implementation and security.

Snapshot generated from the HN discussion

Discussion Activity

Very active discussion

First comment

Peak period

Day 8

Avg / period

Comment distribution30 data points

Loading chart...

Based on 30 loaded comments

Key moments

01Story posted
Oct 15, 2025 at 2:29 AM EDT
3 months ago
Step 01
02First comment
Oct 22, 2025 at 6:39 AM EDT
7d after posting
Step 02
03Peak activity
28 comments in Day 8
Hottest window of the conversation
Step 03
04Latest activity
Oct 24, 2025 at 1:35 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (32 comments)

Showing 30 comments of 32

tialaramex

3 months ago

3 replies

"Real-World Software" maybe but not real world effectiveness.

A lot of effort was expended on modelling the hypothetical thing Argon2 is good at, but a reasonable question is: Does that make any real world difference? And my guess is that the answer, awkwardly, is approximately No.

If you use good passwords or you have successfully stopped using passwords in the decades we've known they're a bad idea, Argon2 makes no difference at all over any of the other reasonable choices, and nor does its configuration. If you figure that nobody will remember your password is hunter2 then Argon2 can't help you either. If the attack being undertaken is an auth bypass, Argon2 can't help. If they're stealing credentials, Argon2 can't help.

creatonez

3 months ago

Most people's passwords are in the category of "moderately weak, but not necessarily leaked to the public". If you are to accept passwords at all, you are responsible for protecting these users who have an expectation that your service is no worse than any other service's ability to protect passwords. There is no way surefire to force users to pick a truly entropic password. So an adequate amount of key stretching is not optional.

In a way, adequate password stretching helps to treat passwords as the toxic sludge they are. The goal is to store them in the most irrecoverable possible format, regardless of the poor decisions of the users who entered those passwords, so that you as the service don't end up being the one making the problem worse.

integralid

3 months ago

Most people don't use password managers and their passwords are very weak - Argon2 helps here. And even if your use a password that most would consider strong, if something like md5 is used then modern gpsu can do a crazy number of operations per second and have a serious shot at breaking then - Argon2 helps here. Not every programmer knows how to handle passwords properly, and may forget to use salt. Argon2 makes this impossible, and helps here. Finally when comparing to something like bcrypt, improvements are less significant, but improved gpu resistance won't hurt. And bcrypt has weird implementation quirks (password length restriction) that lead to real world vulnerabilities, argon does not.

In short, I disagree.

helpfulclippy

3 months ago

Strong hashes aren’t so useful for you the individual with a high entropy per-site password… they’re useful for responsible organizations trying to proactively mitigate the impact of a future data breach on users with bad password habits (which is a lot of users).

If ClownCo gets hacked that’s bad. If ClownCo gets hacked and discloses millions of sets of credentials, it is now enabling a new wave of credential stuffing attacks.

palantird

3 months ago

1 reply

> ... 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.

swiftcoder

3 months ago

1 reply

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

luizfelberti

3 months ago

1 reply

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...

tptacek

3 months ago

1 reply

It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.

linsomniac

3 months ago

1 reply

Do you have a better recommendation?

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

rubendev

3 months ago

2 replies

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...

akerl_

3 months ago

2 replies

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.

rubendev

3 months ago

1 reply

Yes I fully agree. I’m a big fan of libraries like Google Tink that make you pick a use case and use the best implementation for that use case with built in crypto agility.

Most crypto libraries are not built like that however. They just give you a big pile of primitives/algorithms to choose from. Then frameworks get built on top of that, not always taking into account best practices, and leave people that are serious about security the job of making sure the implementation is secure. This is the point where you need something like ASVS.

akerl_

3 months ago

1 reply

What language today still doesn't have a de facto simplified toolbox for wrapping crypto operations?

If you're a developer, and you start trying to perform crypto operations for your service and the library you chose is making you question which cipher, what KDF parameters, or what DH group you want, that is 100% a red flag and you should promptly stop using that crypto library.

rubendev

3 months ago

Can you give some examples of such commonly used libraries for languages like Java / C# / C++?

In my experience there are not many libraries like Google Tink around, and they are not in widespread use at all. Most applications doing encryption manually for specific purposes still have the words AES, CBC, GCM, IV etc hardcoded in their source code.

If you review such code, it’s still useful to have resources that show industry best practices, but I agree that the gold standard is to not have these details in your own code at all.

rubendev

3 months ago

1 reply

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...

tptacek

3 months ago

1 reply

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

rubendev

3 months ago

Please elaborate why you believe that? The ability to easily rotate encryption keys is considered an anti pattern?

tptacek

3 months ago

1 reply

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.

rubendev

3 months ago

1 reply

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.

tptacek

3 months ago

1 reply

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.

rubendev

3 months ago

Which one would you recommend instead? Referring dev teams to NIST standards or the like doesn’t work well in my experience.

gregoriol

3 months ago

2 replies

It seems that PHP, Symfony, ... have kept bcrypt as their preference even when Argon2 is available; is there a rationale there from such big projects?

tptacek

3 months ago

bcrypt is fine. scrypt is fine. Argon2 is fine. Even PBKDF2, in most configurations, is fine. You can basically just put them on a board and throw a dart.

upofadown

3 months ago

There is some thought that bcrypt is better than Argon2 for run times less than a second. So passwords in other words.

atoav

3 months ago

1 reply

For a university self service portal that was a green field project I selected Argon2 as the password hashing algorithm. For evaluation I went pretty deep into how to implement password storage myself, to then opt for OpenLDAP, which we use now.

I really liked what I saw there. Argon2 has some adjustable settings for hash complexity that allow you to select your own tradeoff between cracking resistance and resource use. And not only that Argon2 provides everything needed to rehash on the fly when these setting change, which makes it really future-proof.

The (offical) argon2 libraries I used were all well written and documented, the integration into OpenLDAP very straight-forward. One painpoint we had was with OpenRadius, that instead of just asking the LDAP server to check a password decides to read the hash from LDAP and then try to verify it. And of course Argon2 is not supported..

We found another better alternative way of achieving the same, without OpenRadius. I don't really know the details here, but as of now (3 years in) we are still very happy with the choice.

creatonez

3 months ago

> And not only that Argon2 provides everything needed to rehash on the fly when these setting change, which makes it really future-proof.

Argon2 itself doesn't necessarily provide this. Rather, this comes from convention and best practices implemented in various password libraries. The unix `crypt` syntax (`$id$rounds=yyy$salt$encrypted`) has been adapted for use with PBKDF2, bcrypt, scrypt, Argon2, etc. by a handful of libraries, and helps you store the algorithm and parameters in the same string so that having multiple formats and updating old ones is trivial. But it's not required for Argon2 implementers and was never mentioned in the original paper - the algorithm itself just specifies a function that returns raw bytes.

It's definitely nice to have, though. For the purpose of password hashing (which isn't necessarily the only thing Argon2 is good for), I wouldn't use a library that didn't have some sort of hash upgrade helper.

silisili

3 months ago

1 reply

I feel like my biggest issue last time I implemented Argon2 was which settings to use. There are so many different opinions, people posting helpful but untrue info, etc that it gets a bit mind boggling on what to actually believe. I spent hours on it and still didn't really find a sane consensus. I'm sure it makes more sense to someone in the crypto space, but this has got to be easier for widespread adoption. Sane defaults, or 'here are 3 example groups of settings and when it's recommended.'

In the end I gave in and just used what Bitwarden uses. I figured they probably knew what they were doing more than I did.

braiamp

3 months ago

OWASP usually gives you sane defaults https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

upofadown

3 months ago

>...OWASP's recommended 46 MiB configuration reduces compromise rates by 42.5% compared to SHA-256...

Not sure that is a good comparison. The competition is against things like scrypt not raw hashes.

The default suggested 2GB Argon2 memory requirement is likely putting people off so there certainly is room for a different suggestion. It is just too bad this stuff wasn't worked out at the beginning.

franciscop

3 months ago

This reminded me to check, and now I'm happy to see Argon2 has finally made it into Node.js core!

https://github.com/nodejs/node/issues/34452

2 more comments available on Hacker News

View full discussion on Hacker News

ID: 45588752Type: storyLast synced: 11/20/2025, 12:35:35 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN