Curtis, Could you describe how often does the problem happen? How many session users goes to the site? You mentioned about a month of public usage. During that month, did you have one single incident? How many sessions happened during that month? All key-based session management systems are intrinsically unsafe, since other people can tap into your session, with non-zero probability, if the key-length is finite. The only hope is to make the key long enough, so even if the hacker has a supercomputer, it would still take him/her the age of the universe to crack into your website. One thing I mentioned to Pavlos (and/or Anthony Baxter?) before is that the key lengths of their cookies are a bit too short. For my HappySession product (another session management product, which is RAM based), I cranked up the key length to 128 alphanumeric char key, exactly because I wanted no key collision for a long long time. :) Another thing I observed during the development of HappySession was that on Linux (and Debian) server systems, I had problem with deleting the cookies of the clients. (No problem with NT server.) At the end, I chose not to delete cookies but instead setting their values to blank, when the session expires. It was a weird problem, I did not know why I couldn't delete client cookies (maybe it was a mistake on my part), but I chose the simple way out by setting the cookie to blank. And it worked fine. So instead of detecting the presence of the cookie alone, I detected the presence AND whether the cookie was blank. regards, Hung Jung _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
On Thu, 31 Aug 2000, Hung Jung Lu wrote:
Curtis,
Could you describe how often does the problem happen? How many session users goes to the site? You mentioned about a month of public usage. During that month, did you have one single incident? How many sessions happened during that month?
So far, we have one recorded incident, and one anecdotal (from internal) incident. I am having some more extensive testing done soon, so we can try to pin down further the exact circumstances which cause this problem. The site is used for issuing product return authorities, and so far, over 160 RAs have been issued. Yes, it is a fairly low traffic site. Session data is retained between visits (a side effect, but a welcome one), so I really cannot be sure of how many sessions were used.
All key-based session management systems are intrinsically unsafe, since other people can tap into your session, with non-zero probability, if the key-length is finite. The only hope is to make the key long enough, so even if the hacker has a supercomputer, it would still take him/her the age of the universe to crack into your website. One thing I mentioned to Pavlos (and/or Anthony Baxter?) before is that the key lengths of their cookies are a bit too short. For my HappySession product (another session management product, which is RAM based), I cranked up the key length to 128 alphanumeric char key, exactly because I wanted no key collision for a long long time. :)
Well, yes and no. This really depends on the sensitivity of your data, and how likely it is for someone to try to crack your site. In this case, both are fairly low, so the key strength is fine, IMHO.
regards,
Hung Jung
participants (2)
-
Curtis Maloney -
Hung Jung Lu