Ticket #3460 defect reopened
Session UID might be predictable
|Reported by:||mthuurne||Owned by:||jknight|
Each Session object has a UID to identify it. This UID is generated by Site._mkuid() from a random number (from Python's Mersenne Twister) and a counter. Then an MD5 sum is computed over the string representation of both.
If the same Python process uses the same random generator (global instance from the "random" module) for outputting non-hashed values as well, an attacker would be able to learn the current state of the random generator and predict the next random number. Since the counter is also predictable, guessing the next session UID would be simple.
Is the UID intended to be secure, or is it only intended to have a low chance of collisions with other UIDs?
If it is not intended to be secure, please document this clearly, so programmers who require a secure ID know that they have to add it themselves.
If it is intended to be secure, one way of fixing it would be to use a secure random generator for generating the UID. Ticket #2685 describes a secure random generator for use by Twisted classes.
A possible way to reduce UID predictability is to instantiate a random generator which is used only for creating UIDs, instead of using a shared instance. Since all outputs based on these random numbers are hashed, it will be much harder to discover the state of the random generator. My crypto knowledge is not sufficient though to say whether this would make it secure or just less insecure, so the safer bet would be to use a secure random number.