[Python-ideas] Python's Source of Randomness and the random.py module Redux

Donald Stufft donald at stufft.io
Thu Sep 10 13:26:56 CEST 2015


On September 10, 2015 at 4:41:56 AM, Paul Moore (p.f.moore at gmail.com) wrote:
> On 10 September 2015 at 01:01, Donald Stufft wrote:
> > Essentially, there are three basic types of uses of random (the concept, not
> > the module). Those are:
> >
> > 1. People/usecases who absolutely need deterministic output given a seed and
> > for whom security properties don't matter.
> > 2. People/usecases who absolutely need a cryptographically random output and
> > for whom having a deterministic output is a downside.
> > 3. People/usecases that fall somewhere in between where it may or may not be
> > security sensitive or it may not be known if it's security sensitive.
>  
> Wrong.
>  
> There is a fourth basic type. People (like me!) whose code absolutely
> doesn't have any security issues, but want a simple, convenient, fast
> RNG. Determinism is not an absolute requirement, but is very useful
> (for writing tests, maybe, or for offering a deterministic rerun
> option to the program). Simulation-style games often provide a way to
> find the "map seed", which allows users to share interesting maps -
> this is non-essential but a big quality-of-life benefit in such games.

This group is the same as #3 except for the map seed thing which is
group #1. In particular, it wouldn’t hurt you if the random you were
using was cryptographically secure as long as it was fast and if you
needed determinism, it would hurt you to say so. Which is the point
that Theo was making.

>  
> IMO, the current module perfectly serves this fourth group.

Making the user pick between Deterministic and Secure random would serve
this purpose too, especially in a language where "In the face of ambiguity,
refuse the temptation to guess" is one of the core tenets of the language. The
largest downside would be typing a few extra characters, which Python is not
a language that attempts to do things in the fewest number of characters. 

>  
> While I accept your point that far too many people are using insecure
> RNGs in "generate a random password" scripts, they are *not* the core
> target audience of the default module-level functions in the random
> module (did you find any examples of insecure use that *weren't*
> password generators?). We should educate people that this is bad
> practice, not change the module. Also, while it may be imperfect, it's
> still better than what many people *actually* do, which is to use
> "password" as a password on sensitive systems :-(

You cannot document your way out of a UX problem.

The problem isn’t people doing this once on the command line to generate
a password, the problem is people doing it in applications where they
generate an API key, a session identifier, a random password which they
then give to their users. If you give a way to get the output of the MT
base random enough times, it can be used to determine what every random
it generated was and will be.

Here’s a game a friend of mine created where the purpose of the game is
to essentially unrandomize some random data, which is only possible
because it’s (purposely) using MT to make it possible
https://github.com/reaperhulk/dsa-ctf. This is not an ivory tower paranoia
case, it’s a real concern that will absolutely fix some insecure software
out there instead of telling them “welp typing a little bit extra once
an import is too much of a burden for me and really it’s your own fault
anyways”.

> 
> Maybe what Python *actually* needs is a good-quality "random password
> generator" module in the stdlib? (Semi-serious suggestion...)
>  
> Paul
>  

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA




More information about the Python-ideas mailing list