-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about default parameters #6
Comments
Hi, Sure, I'd be happy to discuss changing the default parameters. If we can determine better ones then I am all for it.
I would guess that most machines running this are doing other things too, like serving some form of web application/API. So they need to still be able to do other useful work at the same time as hashing a password. For that reason, I'm not sure if using all CPUs would be a good default. Maybe With regard to the number of iterations, it would probably be sensible to align with the RFC recommendations and the
It's worth bearing in mind that slow is not necessarily the same thing as expensive. Potentially, a bcrypt hash may take longer to create than a argon2 hash, but it doesn't mean that it is necessarily less expensive (due to the argon2 memory and parallelism requirements). More expensive is better, especially when trying to defend against an offline attack (weak/common passwords will still be broken, even with a very expensive hashing algorithm), but this has to be balanced against other requirements like signup/login calls not taking too long to complete. I think it might be worth adding a stronger note to the documentation for the default parameters. Something like:
|
Thanks for the clarifications! I agree that it doesn't make sense to make the parallelism default dynamic, that's better left for the parent application. The confusing part about 3 iterations was just that the comments didn't explain why that specific default was chosen. So, the proposed changes would be:
|
Those changes sound sensible to me. For point 3, let's use 1 iteration and quote the spec. As a point 4, like I mentioned above, I think we should a warning to the default parameter similar to this:
Would you like to make the changes and send a PR? |
Opened a PR. Also, in case you aren't subscribed to golang/go#16971, it looks like it's getting accepted. |
Clarify default parameters. Fixes #6.
Thank you for this package, it's just what I needed.
Since forever I've relied on bcrypt's simplicity, where there's only one knob to turn, and the default value (10 in Go and PHP) seems sufficient. Argon2 introduces a whole set of knobs, and the defaults across languages vary significantly.
So, I was wondering how the DefaultParams were chosen, and whether the package should provide more guidance on expected defaults.
Parallelism
Would it be safe to recommend always setting this to at least uint8(runtime.NumCPU())?
Iterations
My confusion here was regarding the different defaults between this package, the underlying golang package (x/crypto/argon2), and libsodium.
This package defaults to t=3. libsodium defaults to 2 for the interactive preset, which is also used as the default for PHP's password_hash().
The /x/crypto/argon2 docs for argon2id say:
The RFC says:
I see the same text in the most recent version: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-8.3
So, the question here is whether it makes sense to follow the spec in defaulting to 1, and placing emphasis on increasing memory (as the primary hardening parameter)? Should we always aim to make the hashing process as slow as possible, or is there a point at which the result is good enough?
(Benchmarks on my MBP show t=1 with 64M and 4 threads taking around 30ms, t=2 taking around 60ms. bcrypt with 10 rounds taking ~70ms)
The text was updated successfully, but these errors were encountered: