First of all, your session timeout length should be as short as you can possibly make it. There is no magic number here, it is really based upon how long your users are expected to be on a page before they next click on a link (and therefore renew the session and reset the timeout). This timeout value (of course) is stored in the database, and if it's value is shown to be in the past, then the session is expired and a user should be prompted to log in again. I find that 20-30 minutes is enough for most applications.
This takes care of old sessions, the double login issue is somewhat trickier, and you have a few choices. Assuming your session is somehow related to your user's account in some way, you can do it a few different ways.
You can force a new valid login to log-out any previous or current logins of the same user account. In turn forcing the expiration of the current session associated with that users account (and logging out the physical user associated it).
The problem with this is that a potentially "stolen" login would kick out a "valid" login (or vice-versa). It provides no way to assure that a user is who they say they are, but truthfully, you can never really know this.
You can track the IP address (or some other machine identifier) of the current session somewhere in your database (or as a part of your session id somehow), and allow new logins from that machine address to override an orphaned sessions. For added "security", you can constrain this action within certain period of time (preferably shorter than the session timeout length).
The drawbacks of this approach are again that you can never know if your user is truely who they say they are. The machine itself may have been compromised, or the IP spoofed. The problem might also arise if a user were to need to transfer machines because of a system crash or some other catostrophic event, they would need to wait out the session timeout. Since this is an extrordinary circumstance, this might be ok. Although things like DHCP and dropped dial-in connections could play havoc with this if you use IP addresses as your machine identifier.
There are always cookies. I personally do not like cookies for session management, I think they are clunky myself. But with cookies, you can have a dialog between the server and the client. If you do not set the cookie's expriation date, most browsers will consider closing the browser the expiration of that cookie. You can use this to take care of your "user closes browser but doesn't log out" problem. This however does not disallow dual-logins by itself, that needs to be a matter of policy in the database still.
But there is no guarantee (that i know of) of these things working on all platforms/browsers so you will need to test it on your target platforms.
Alot of these issues should be discussed with your client/user-base to find out what is either the prefered method, or the method that conforms best to existing security policies.
Hope this helps in some way.
-stvnIn reply to Re: How should I handle Orphan Sessions?
by stvn
in thread How should I handle Orphan Sessions?
by soon_j
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |