On 16 June 2016 at 16:58, Nathaniel Smith <njs@pobox.com> wrote:
The word "cryptographic" here is a bit of a red herring. The guarantee that a CSPRNG makes is that the output should be *unguessable by third parties*. There are plenty of times when this is what you need even when you aren't using actual cryptography. For example, when someone logs into a web app, I may want to send back a session cookie so that I can recognize this person later without making then reauthenticate all the time. For this to work securely, it's extremely important that no one else be able to predict what session cookie I sent, because if you can guess the cookie then you can impersonate the user.
In python 2.3-3.5, the most correct way to write this code is to use os.urandom. The question in this thread is whether we should break that in 3.6, so that conscientious users are forced to switch existing code over to using the secrets module if they want to continue to get the most correct available behavior, or whether we should preserve that in 3.6, so that code like my hypothetical web app that was correct on 2.3-3.5 remains correct on 3.6 (with the secrets module being a more friendly wrapper that we recommend for new code, but with no urgency about porting existing code to it).
While your example is understandable and clear, it's also a bit of a red herring as well. Nobody's setting up a web session cookie during the first moments of Linux boot (are they?), so os.urandom is perfectly OK in all cases here. We have a new API in 3.6 that might better express the *intent* of generating a secret token, but (cryptographic) correctness is the same either way for this example. As someone who isn't experienced in crypto, I genuinely don't have the slightest idea of what sort of program we're talking about that is written in Python, runs in the early stages of OS startup, and needs crypto-strength random numbers. So I can't reason about whether the proposed solutions are sensible. Would such programs be used in a variety of environments with different Python versions? Would the developers be non-specialists? Which of the mistakes being made that result in a vulnerability is the easiest to solve (move the code to run later, modify the Python code, require a fixed version of Python)? How severe is the security hole compared to others (for example, users with weak passwords)? What attacks are possible, and what damage could be done? (I know that in principle, any security hole needs to be plugged, but I work in an environment where production services with a password of "password" exist, and applying system security patches is treated as a "think about it when things are quiet" activity - so forgive me if I don't immediately understand why obscure vulnerabilities are important). I'm willing to accept the view of the security experts that there's a problem here. But without a clear explanation of the problem, how can a non-specialist like myself have an opinion? (And I hope the security POV isn't "you don't need an opinion, just do as we say"). Paul