-
-
Notifications
You must be signed in to change notification settings - Fork 437
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
Remarks on password generation (2) #995
Conversation
src/distributions/other.rs
Outdated
/// as a password. `Alphanumeric` generates from an alphabet of 62 symbols, thus | ||
/// each character can provide `log2(62) = 5.95...` bits of entropy. We suggest | ||
/// consulting external sources for more. One may start with the | ||
/// [Wikipedia article on Password Strength](https://en.wikipedia.org/wiki/Password_strength). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is a bit confusing to mention the question without answering it. I understand that we want to avoid making inaccurate statements about security. Maybe we should emphasize that the default RNG in Rand is designed to be unpredictable and thus suited for generating passwords, but that it is more conservative to use getrandom
(or the equivalent randomness implementations in crypto libraries).
I would maybe emphasize that giving recommendations about the strength/length of passwords is out of scope for Rand.
There are two things that are needed for secure passwords:
There are various recommendations for the latter item, ranging from 128 or even 256 bits, down to 77 bits, as explained in a very recent blog article by @espadrine. Advice on password generation is better suited in places where the RNG involved is definitely a cryptographic RNG. For example, there is password generation code in the documentation for Python's |
I'm afraid it is a bit more complicated, because the minimum number of bits required depends on the threat model, the key-derivation function, the possibility of offline attacks, rate limiting, the lifetime of the key, etc. I'm not sure it makes much sense to go into detail within the scope of Rand.
In the Note that Python's |
I suggest @vks make the next pass at improving this? You should be able to push directly to this branch rather than needing a new PR. |
I suppose the code should go elsewhere.
@dhardy This is what I was thinking. |
Looks very good to me. @peteroupc your thoughts? Ironically GitHub won't let me review because I am an author, but I can force-merge anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved by @dhardy.
I merged it. If anyone has followup questions or remarks, please comment here or open a new issue. |
Since #942 has not been resolved, I simplified the advice and removed the example code (which is less important than the advice).
@burdges @bjorn3 @vks @peteroupc may or may not wish to comment. Closes #942.