Enhancement: CSPRNG instead of Random
Closed this issue · 4 comments
When creating the access token, Random() is used, which uses the Mersenne Twister PRNG algorithm. Even though Python seems to seed decently when entropy sources are available on OS-level, I'd encourage the use of a cryptographically-secure pseudorandom number generator instead.
Our approach was to hand off most of the 'heavy duty' work to existing, well tested 3rd party code but also to keep the number of dependencies minimal.
TBH i cannot properly judge whether the benefit of using an advanced random number generator might not be outweighed by the disadvantage of introducing an additional dependency. i'm a big fan of python's included batteries :)
can you cite any specific concerns or advantages that might help to make an educated decision here?
I'm a security guy, not a Python, guy, but I assume ssl.RAND_bytes() is part of the core (that's particularly well-tested randomness from openssl - unless you are on a really old Debian machine ;-)? I don't have a real attack against Random(), but the documentation clearly states that it should not be used for security purposes (see e.g. http://docs.python.org/dev/library/random.html).
excellent point. IOW use better batteries :)
this has been addressed in 0e70281 and has been released in 0.1.3
note: SSL.RAND_bytes is only available in Python 3, which we currently don't support (although our setup should, in theory, run just fine in Python3).
instead we now use the random generator of the OS.
feel free to re-open, but for now i'm closing this. thanks again.