"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.
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.
> 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.
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.
>...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.
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.
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.
11 comments
[ 4.5 ms ] story [ 33.2 ms ] threadA 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.
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.
> 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.
https://github.com/nodejs/node/issues/34452
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.
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.
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.