Tim, The userkey, as you may expect defines what differentiates one user/visitor/session from another.
Since every request either picks up an existing user reference from one of the pass-in values (session cookie, search arg, or post arg) or gets a new user reference assigned, your setting essentially means that each user is distinct based on user reference. Let’s look at 3 scenarios where you may want to key the user scope off of more than the user reference alone: 1) Same user, using the same browser, accessing two different domains on your server. In this case, the automatic support and function of the session cookie would make the browser create two different user keys, however if you were passing the user reference by argument, you would affectively allow the user key to be reused on both domains, which if they were completely different sites, could be a problem. To account for this your userkey would be: <@USERREFERENCE><@DOMAIN> 2) Different computer (thus IP address), accessing the same site. In this case, again this is only easy to do when the user reference is passed in via argument, but can be hacked by a knowledgeable user, the user reference was somehow transmitted to another computer, such as an emailed link. To prevent this kind of user session “stealing” you would want to differentiate the user session by IP. Your userkey would be: <@USERREFERENCE><@HTTPATTRIBUTE client_ip>. Right away this looks like a great idea, however, due to proxy servers and PAT routers, it’s possible, that one user would have multiple IPs and likely that multiple users can originate from one IP. 3) Same user, same computer, different browsers. In this case you have a user with a good session on one browser who opens up another browser, copies the URL and steals their own session. Since the user reference (again passed as an argument) and the IP are the same, the above solution doesn’t create separation. The solution here is to set the userkey to: <@USERREFERENCE><@HTTPATTRIBUTE user_agent> As you can see, due to the IPv4 conservation tricks, adding the client IP address to the key is not necessarily useful. The documentation is in this case outdated, and the current use of just the <@USERREFERENCE> alone is the recommended setting. Other keys could be made, for example, if you wanted to invalidate all your user sessions at midnight, you could make the key <@USERREFERENCE><@CURRENTDATE>. Additionally, all simple cases of session hacking are caused by the argument passed user reference being copying and sent to another user/computer/browser. It is the current recommendation to never user pass the user reference argument. I plan to add a switch in a future version to permanently disable this feature, both the writing (<@USERREFERENCEARGUMENT>) and the reading done in the module. This would essentially force the use of the session cookie, which is the safest method to use. Hope that helps. Let me know if you have any other questions. Session hijacking, which is directly attached to this topic is an important security topic and I’m interested in making TeraScript as secure as possible out-of-the-box. Robert From: Tango-Talk [mailto:tango-t...@hudce7.harvard.edu] Sent: Thursday, September 15, 2011 11:01 AM To: Witango-Talk@witango.com Subject: Witango-Talk: Userkey question We've been reviewing our site setup and noted that our system$userkey is set to <@userreference>. The documentation often includes <@httpattribute client_ip> (or <@cgiparam client_ip>) as part of the key. Is this a best practice? Does it add any security benefit? Thanks ------------------------------ Tim Kelley Executive Director of MIS Harvard University - DCE e-mail: tim_kel...@harvard.edu _____ To unsubscribe from this list, please send an email to lists...@witango.com with "unsubscribe witango-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to lists...@witango.com with "unsubscribe witango-talk" in the body.
