Comments (4)
Hi,
Sure, I'd be happy to discuss changing the default parameters. If we can determine better ones then I am all for it.
Would it be safe to recommend always setting this to at least uint8(runtime.NumCPU())
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 min(1, floor(numCPU/2))
would be a better default than the current default of 2? The only thing that I feel uncomfortable about with that is that the default parallelism value is then dynamic, and that could potentially cause issues/confusion when running the same code in different environments.
With regard to the number of iterations, it would probably be sensible to align with the RFC recommendations and the /x/crypto/argon2
docs and default this to 1. I think the reason that I set it higher in the defaults is because I found in benchmarking that the hashing tended to complete quite quickly, even when bound to 2 CPUs, and guessed that most applications could afford a longer delay.
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?
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:
The default parameters should generally be used for development/testing purposes only. Custom parameters should be set for production applications depending on available memory/CPU resources and business requirements.
from argon2id.
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:
- Document the "between 1 and numCPU" guideline for parallelism, keeping the current default (2).
- Document that the primary knob to turn is memory.
- Modify the default iterations to 1, documenting that it was chosen because it is recommended by the spec (quoting the relevant part perhaps), or to 2 (if we want more expensive defaults), documenting that it was chosen to match libsodium as a more expensive alternative to the spec recommendation.
from argon2id.
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:
The default parameters should generally be used for development/testing purposes only. Custom parameters should be set for production applications depending on available memory/CPU resources and business requirements.
Would you like to make the changes and send a PR?
from argon2id.
Opened a PR.
Also, in case you aren't subscribed to golang/go#16971, it looks like it's getting accepted.
from argon2id.
Related Issues (14)
- Password matches with invalid hashes HOT 3
- Feature request: Derived key from hash (IDKey) HOT 2
- DecodeHash must check if hashed password uses argon2id HOT 1
- To big memory consumption HOT 3
- Version Tag HOT 1
- golang.org/x/crypto dep should uptdae HOT 3
- CompareHashAndPassword
- CreateHash and others should provide byte variants HOT 2
- huge memory allocation HOT 2
- IDKey vs ID HOT 2
- Update documentation in Changing the Parameter HOT 1
- Fix Test case HOT 1
- support for pepper? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from argon2id.