> >> By playing around in a python session it seems that the call to the > >> system randrange with random.SystemRandom().randrange(0, > >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 > >> minutes) whereas a call to the "normal" randrange with randrange(0, > >> _MAX_CSRF_KEY) happily returns the desired random number.
This sounds like python is unable to get a secure random number from the OS. The OS can run out of entropy, it may even happen faster on shared systems. http://www.entropykey.co.uk/ says (and they probably know): "Applications that require random data, [...] read from this pool. The problem is that the pool is of fixed size (just 4kB) and as standard has limited entropy input. If an application tries to read from the pool, and there is not enough data to satisfy its request, the application is frozen in limbo until enough entropy has been collected to fill the pool to the point of being able to satisfy the request, leading to delays in the delivery of services." Sounds like what happened to you. > I'm unclear on why we even allow this code to work with the "default" > random implementation, which is based on a Messrne Twister, and > (quoting the Python docs here), "is completely unsuitable for > cryptographic purposes". To my understand that's how we're trying to > use it, and if I'm wrong here I wonder why we give preference to the > system random at all? If DEBUG=False, there shouldn't be a fallback to non-secure random numbers, maybe there shouldn't even be a fallback at all. If the host has not enough entropy, Django shouldn't fix it, an administrator should. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
