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