[Python-ideas] Pre-PEP Adding A Secrets Module To The Standard Library

Steven D'Aprano steve at pearwood.info
Mon Sep 21 19:47:58 CEST 2015

On Sun, Sep 20, 2015 at 11:56:06AM +0100, Paul Moore wrote:
> On 20 September 2015 at 00:40, Tim Peters <tim.peters at 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:


> 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.


More information about the Python-ideas mailing list