[Twisted-web] Session class

[Maarten ter Huurne]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081004/9829bb50/attachment.pgp