[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:
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
More information about the Python-ideas
mailing list