Session Variables VS Query Strings VS Cookies 1

[fischadler]

Some time ago I used to use session variables in order to store login information (such UserID and whether they are logged or not). This worked fine until one fine day one the servers I hosted my sites on started resetting sessions sporadically, sometimes after the 30 minutes (as it was set both through code and throu IIS6) and sometimes after am arbitrary number of minutes. This "randomly expiring sessions in IIS6" problem seems to be very common cos I read about it in various forums, but I only found complaints - no solutions.

Then I started storing the login inofrmation as encrypted data inside the URL. This data was passed from page to page when the logged in users navigated from page to page. This worked but was very complex and generated a lot of bugs. Besides, I have some doubts about it security wise.

Now I thought I could start using cookies (without an expiry so that they expire when the browser is closed). Seems to be working fine in the experiments. The server I am testing on handles session variables properly, but at some point I will probably have to migrate to onther server that is not yet built.

My question is: Am I opening up myself to further problems or security loopholes by using this last method?

-Fischadler

 

[MikeBronner]

The drawback with cookies is that you cannot rely on them. Users may delete cookies, they can alter them (i.e. to try to hack your system). However, URL-based solutions have the same problem.

As long as you are storing the user ID to remember who is using your app you will be ok. Never store authentication information or passwords in a cookie.

To make the app a little more secure, I would store the user id in the cookie, as said above. However, I would add a column to the user table, called something like user_ip, to store the IP address the user logged in with.
Then on each page you look up the IP address using the user ID in the cookie and compare it to the IP address the user is at. If they differ, send the user to the login page. If they are the same, you can be fairly sure that the user is who he says he is. (It is still hackable, but much more difficult.)

Good luck!
Mike

 

[fischadler]

OK. Thanks for the advice!

-Fischadler