Skip to content
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

Merged
merged 3 commits into from Aug 4, 2020
Merged

Remarks on password generation (2) #995

merged 3 commits into from Aug 4, 2020

Conversation

dhardy
Copy link
Member

@dhardy dhardy commented Jul 7, 2020

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.

/// 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).
Copy link
Collaborator

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.

@peteroupc
Copy link

peteroupc commented Jul 7, 2020

There are two things that are needed for secure passwords:

  • A cryptographic RNG (which not all RNGs in Rand are).
  • A suitable security strength, in bits of entropy.

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 secrets module (a cryptographic RNG module), as opposed to in its random module. Also, not all "random strings" that people want to generate will be user-facing. Many "random strings" serve not only as passwords, but also session, account, and other identifiers; one-time verification tokens; and other unique values. For non-user-facing strings, however, the string need not be in a memorable format and can, for instance, be in base64.

@vks
Copy link
Collaborator

vks commented Jul 7, 2020

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.

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.

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 secrets module (a cryptographic RNG module), as opposed to in its random module.

In the rand crate, all RNGs are cryptographic, unless you opt into the small_rng feature. Maybe we should mention CryptoRng in the documentation on passwords?

Note that Python's random module exclusively implements RNGs which can be predicted by observing their output, so the situation is not the same as in Rand. However, crypto crates such as ring come with their own randomness API, and discuss and implement key-derivation functions etc., so maybe we should refer to them instead of duplicating the advice on passwords and key derivation.

@dhardy
Copy link
Member Author

dhardy commented Jul 31, 2020

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.

@vks
Copy link
Collaborator

vks commented Aug 1, 2020

@dhardy This is what I was thinking.

@dhardy
Copy link
Member Author

dhardy commented Aug 1, 2020

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.

Copy link
Collaborator

@vks vks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved by @dhardy.

@vks vks merged commit dca9cb5 into master Aug 4, 2020
@vks vks deleted the password branch August 4, 2020 15:29
@vks
Copy link
Collaborator

vks commented Aug 4, 2020

I merged it. If anyone has followup questions or remarks, please comment here or open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Generating Secure Random Passwords
4 participants