[Zope] CoreSessionTracking: Brute-Forcing Web Application Session IDs

[Chris McDonough]

> It's very cost effective to integrate a hash and a secret: It does
> cost nearly nothing for you, the maintainer of CoreSessions and it
> really costs nothing besides a few CPU cycles for the sites using
> it. But it makes it *much* harder for potential attackers to go for
a
> session id.
> So I think it should be done:)

OK, so do you recommend that I just use a shared secret string to
obfuscate the session id?  I suppose I could just use the rotor module
to do this and come up with some URL-compatible way of representing a
rotor'd string.  Then I'd need to give folks some way to specify a key
for rotor to use.  I'd need to provide a default.  And the actual
browser id string would be really long.  Ugh.

Or do you think I should use dates/times and IP addresses as part of
the string, rejecting session ids from machines that don't match the
IP address encoded into the sid and date/times that are too long ago?
Note that I believe there will be some cost involved in terms of
documentation and support if this is the case.  Sessions often just
won't work due to proxy server banks that prevent users from appearing
to come from the same IP address across requests.

Maybe there could be a knob to turn "ultrasecure" behavior on and off.
It could be off by default, and as part of turning the knob on, you'd
need to specify a rotor key and nominally you'd also know that
sessions stood a chance of not actually working if they incorporated
the IP address as part of the hash.

In any case, if anything like this goes in, this will be a feature of
a sessioning system after Zope 2.5 and will not ship with 2.5.

Thanks Frank!

- C