Man, there's been a lot of movement in this thread. I'd like to just throw out a few comments.
1) The current session framework unquestionably needs some attention. The way in which sessions are being generated isn't terribly efficient, and can certainly lead to collisions. 2) James has suggested that the answer is, perhaps, better seeding. I really don't think that this is an issue. Regardless of the seed, there is still a mathematical chance that a collision will occur. The very definition of random means that you can't predict what will come next. There's a very real chance that any random number generator will give you the exact same number 100 times in a row. It's a small probability, but it is completely possible... any random number generator that tries to avoid this is no longer completely random. The default Python implementation of 'randomness' should be just fine for our purposes. To my knowledge, Mersenne is not cryptographically secure; however, we're not using it for cryptographic purposes... we're using it as input to a hashing function. This brings me to my next point -- hashing. Hashing converts input to a fixed bit-length field. Even if we have truly random and truly unique input to the hashing function, it's possible (again, highly unlikely, but possible) that the result of hashing two inputs will yield the same session key. Unless we're enforcing this at the database level, there's still the possibility of collision. 3) In terms of seeding, the default Python approach should be fine (I can't speak at all to Python 2.3's suitability). It's based on start-up time of the process. It's unlikely that these seed values will occur at the -exact- same moment in time (it is, you guessed it, still possible). Continual reseeding will actually probably make the problem worse, and will degrade performance. In a large deployment with lots of processes continually reseeding, there's a much higher likelihood that they will hit the same seed, and thus generate the same random number pattern. I'm fairly certain that the likelihood of collision here is much higher than using the default Python on-import seeding mechanism. Again, I see the best solution is to move final collision avoidance to the DB. 4) In terms of tying sessions to an IP, I am very much against this. It creates complexity, degrades user experience for some users, and doesn't really add any security. If someone is in a location where they can sniff your traffic, they can very easily spoof your IP. You should be using SSL to encrypt this traffic if you are concerned about this possibility. 5) Thank you to Anton and SmileyChris for bringing this issue front-and-center again. Recap: +1 giving some love to the current session framework +1 ensuring uniqueness at the DB level -1 Giving Django a new RNG -1 Re-seeding on every session generation -1 Tying sessions to IP - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
