[Python-ideas] Python's Source of Randomness and the random.py module Redux
graffatcolmingov at gmail.com
Mon Sep 14 18:25:09 CEST 2015
On September 14, 2015 at 11:08:39 AM, Cory Benfield (cory at lukasa.co.uk) wrote:
> On 14 September 2015 at 16:01, Paul Moore wrote:
> > Why is backward compatibility not being taken into account here? To be
> > clear, the proposed change *breaks backward compatibility* and while
> > that's allowed in 3.6, just because it is allowed, doesn't mean we
> > have free rein to break compatibility - any change needs a good
> > justification. The arguments presented here are valid up to a point,
> > but every time anyone tries to suggest a weak area in the argument,
> > the "we should fix security issues" trump card gets pulled out.
> What makes you think that I didn't take it into account? I did: and
> then rejected it. On a personal level, I believe that defaulting to
> more secure is worth backward compatibility breaks. I believe that a
> major reason for the overwhelming prevalence of security
> vulnerabilities in modern software is because we are overly attached
> to making people's lives *easy* at the expense of making them *safe*.
> I believe that software communities in general are too concerned about
> keeping the stuff that people used around for far too long, and not
> concerned enough about pushing users to make good choice.
> The best example of this is OpenSSL. When compiled from source naively
> (e.g. ./config && make && make install), OpenSSL includes support for
> SSLv3, SSL Compression, and SSLv2, all of which are known-broken
> options. To clarify, SSLv2 has been deprecated for security reasons
> since 1996, but a version of OpenSSL 1.0.2d you build today will
> happily enable *and use* it. Hell, OpenSSL's own build instructions
> include this note:
> > OpenSSL has been around a long time, and it carries around a lot of
> > cruft. For example, from above, SSLv2 is enabled by default. SSLv2 is
> > completely broken, and you should disable it during configuration.
> Why is it that users who do not read the wiki (most of them) get an
> insecure build? Backwards compatibility is why.
So I will counter this with what I am fully expecting to be the response:
People use distributions that compile and configure OpenSSL for them, e.g., `apt-get install openssl` (not obviously the example that works, but you get the idea). That said, last year, Debian, Ubuntu, Fedora, and other distributions all started compiling openssl without SSLv3 as an available symbol which broke backwards compatibility and TONS of python projects (eventlet, urllib3, requests, etc.). Why did it break backwards compatibility? Because they knew that they were responsible for the security of their users and expecting users to recompile OpenSSL themselves with the correct flags was unrealistic. Their users come from a wide range of people:
- System administrators
- Desktop users (if you believe anyone actually uses linux on the desktop ;))
> This is necessarily a reductio ad absurdum type of argument, because
> I'm trying to make a rhetorical point: I believe that sacrificing
> security on the altar of backwards compatibility is a bad idea in the
> long term, and I want to discourage it as best I can.
> I appreciate your desire to maintain backward compatibility, Paul, I
> really do. And I think it is probably for the best that people like
> you work on projects like CPython, while people like me work outside
> the standard library. However, that won't stop me trying to drag the
> stdlib towards more secure defaults: it just might make it futile.
That said, I’d also like to combat the idea that security experts won’t use random. Currently Helios which is a voting piece of software (that anyone can deploy) uses the random module (https://github.com/benadida/helios-server/blob/b07c43dee5f51ce489b6fcb7b719457255c3a8b8/helios/utils.py) They use it to generate passwords: https://github.com/benadida/helios-server/blob/b07c43dee5f51ce489b6fcb7b719457255c3a8b8/helios/models.py#L944 https://github.com/benadida/helios-server/blob/b07c43dee5f51ce489b6fcb7b719457255c3a8b8/helios/management/commands/load_voter_files.py#L55
Ben Adida is a security professional who has written papers on creating secure voting systems but even he uses the random module arguably incorrectly in what should be secure software.
Arguing that anyone who knows they need secure random functions will use them, is clearly invalidated. Not everyone who knows they should be generating securely random things are aware that the random module is insufficient for their needs.
Perhaps that code was written before the big red box was added to the documentation and so it was ineffective. Perhaps Ben googled and found that everyone else was using random for passwords (as people have shown is easy to find in this discussion several times).
That said, your arguments are easily reduced to “No language should protect its users from themselves” which is equivalent to Python’s “We’re all consenting adults philosophy”. In that case, we’re absolutely safe from any blame for the horrible problems that users inflict on themselves.
Anyone that used urllib2/httplib/etc. from the standard library to talk to a site over HTTPS (prior to PEP 466) are all to blame because they didn’t read the source and know that their sensitive information was easily intercepted by anyone on their network. Clearly, that’s their fault. This makes core language development so much easier, doesn’t it? Place all the blame on the users for the sake of X (where in this discussion X is the holy grail of backwards compatibility).
More information about the Python-ideas