On Sun, Sep 20, 2015 at 11:56:06AM +0100, Paul Moore wrote:
On 20 September 2015 at 00:40, Tim Peters <tim.peters@gmail.com> wrote:
.token_alpha(alphabet, nchars) string of `nchars` characters drawn uniformly from `alphabet`
Given where this started, I'd suggest renaming token_alpha as "password". Beginners wouldn't necessarily associate the term "token" with the problem "I want to generate a random password" [1]. Maybe add a short recipe showing how to meet constraints like "at least 2 digits" by simply generating repeatedly until a valid password is found.
I'm not entirely sure about including password generators, since there are so many password schemes around: http://thedailywtf.com/articles/Security-by-PostIt
For a bit of extra bikeshedding, I'd make alphabet the second, optional, parameter and default it to string.ascii_letters+string.digits+string.punctuation, as that's often what password constraints require.
If we're going to offer a simple, no-brainer password generator, my vote goes for: def password(nchars=10, alphabet=string.ascii_letters+string.digits): I wouldn't include punctuation by default, as too many places still prohibit some, or all, punctuation characters. If both my understanding and calculations are correct, using ascii_letters+digits+punctuation gives us log(94, 2) = 6.6 bits of (Shannon) entropy per character, while just using letters+digits gives us log(62, 2) = 6.0 bits per character. For short-ish passwords, up to 10 characters, the extra entropy from including punctuation is less than the extra from adding an extra character: password length of 8, without punctuation: 47.6 bits password length of 8, including punctuation: 52.4 bits password length of 9, without punctuation: 53.6 bits
Or at the very least, document how to use the module functions for the common tasks we see people getting wrong. But I thought the idea here was to make doing things the right way obvious, for people who don't read documentation, so I'd prefer to see the functions exposed by the module named based on the problems they solve, not on the features they provide. (Even if that involves a little duplication, and/or a split between "high level" and "low level" APIs).
I agree that secrets should be providing ready-to-use functions, even if they don't solve all use-cases, not just primitive building blocks. -- Steve