Also, I actually think it's a more effective defense to not rely on a session id to protect data. There was lots of discussion about this when CST was in its infancy, and the decision was to recommend that folks not use sessioning to try to protect sensitive data. The shared-key encryption of a sessionid if IP addresses are not used in the hash seem like only a step above pig latin. Instead if you need to do something sensitive, use a username/password combination.
Does this seem reasonable?
Hi! You are right that sessions might not be the rigth thing to protect really secure stuff, like Extranet access, but I would not want to have anonymous users of a shopping cart application log in with a username and password. These shopping cart applications are where you need both ease of use (which can only be provided by a session) and (at least some) protection. So it is a GOOD THING (TM) to have session ids that are relatively hard to guess. Combined with SSL that seems to be a reasonable thing to do. Joachim