On Friday 03 October 2008, George Pauly wrote: > There are a couple of things I don't understand about Site._mkuid() > > IANAC (I am not a cryptographer). > > Md5 collisions are rare, but (I guess) might theoretically happen > depending on length of input. Does appending the counter to the random > output with an underscore change the statistics of collision?
The random() function returns a 53-bit float, while the MD5 hash is 128-bit, so I think combining the random number with something else does decrease the chance of collisions. However, it would probably be safer to ask the random generator to produce more bits. > Alternatively, perhaps the counter is used as a salt? If so, the salt > does not seem _very_ secret in this case. If a sufficiently strong > random number is used a salt would seem unnecessary. I think the idea is that the random number by itself is already unpredictable enough. But hashing more data will never make it easier to recover the random number and might make it harder, if I understand MD5 correctly. > I've looked at some python code for session keys (Django, something on > activestate that might be Zope code) and they hash together various > things, but not counters. > > I've generated session keys by appending plain-text counters (with an > offset) to random hashes. This guarantees uniqueness & is handy because > it is human readable & you can quickly see how many sessions have been > used since initiation. Of course, the counter value might be sensitive > information in some situations. An encrypted counter might be helpful, > if the object is to have a session key that is guaranteed random and > unique. Or you could just check to see if the key was in use, ala > Django, and leave off the counter altogether. You can check whether there is already an active session with the newly generated UID, but if you want to know for sure whether or not there is an expired session with the newly generated UID, you'd have to remember all UIDs you ever handed out. > One idea from this code (http://code.activestate.com/recipes/52252/) : > > # create a unique session id > > # input - string to use as part of the data used to create the session > > key. # Although not required, it is best if this includes some > > unique # data from the site, such as it's IP address or other > > environment # information. For ZOPE applications, pass in the > > entire ZOPE "REQUEST" # object. > > def makeSessionId(st): > > import md5, time, base64 > > m = md5.new() > > m.update('this is a test of the emergency broadcasting system') > > m.update(str(time.time())) > > m.update(str(st)) > > return string.replace(base64.encodestring(m.digest())[:-3], '/', '$' > > ) I don't know exactly what is in a ZOPE request object, but it's likely to be predictable. A constant string is impossible to mispredict. And the time might not predictable exactly, but if the uncertainty is small enough to make brute forcing it feasible, it's also relatively predictable. A hash of predictable things is itself predictable. The Twisted session UID uses a random number generator which is seeded from a secure random generator (if the OS has one). So assuming the secure random generator does its job well, the initial session UID cannot be predicted. However, from that point on the random generator is completely deterministic, which means that someone who can discover its internal state can generate the same numbers. The problem is that the current implementation uses Python's shared random generator instance, which might be used for other purposes as well and some applications might leak too many hints about the internal state of this shared generator. Although this is not very likely to happen, it is possible and could be avoided by allocating a dedicated generator just for session UIDs. > is to pass in environment info to defend against hijacking. I've used a > very similar method in a stateless (on the server, for cgi) session key > using several environment vars and a salt. This code does not seem to > worry about uniqueness (may be OK, I'm not sure). If collisions are rare enough that the chance of one occurring during the lifetime of the application is neglible, that's close enough to unique for practical purposes. Bye, Maarten
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
