[Twisted-web] Session class
Maarten ter Huurne
maarten at treewalker.org
Fri Oct 3 20:13:13 EDT 2008
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
> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081004/9829bb50/attachment.pgp
More information about the Twisted-web