> 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://argon2-cffi.readthedocs.io/en/stable/parameters.html
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...
I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.
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.
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.
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.
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.
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...
This is a mess, and I would actively steer people away from it.
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.
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.
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.
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.
tialaramex•3mo ago
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.
integralid•3mo ago
In short, I disagree.
helpfulclippy•3mo ago
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.
creatonez•3mo ago
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.