Session Hijacking - regenerate session ID

I've seen implementations that tried this approach and ended up pulling it because yes it can cause resource issues and race conditions across Web farms. It sounds like a good idea at first, but can also make your application more prone to denial of service attacks if the regeneration process is too cryptographically intensive. Answer there is to pregenerate session IDs periodically and keep a cache available, but then you have to manage the cache securely.

Some more common solutions to securing session ID variables is to

• use SSL
• only generate the authenticated session ID after successful login over SSL, else you become vulnerable to session fixation
• generate cryptographically random and unguessable tokens
• expire session IDs frequently
• properly expire then server-side on log out
• mark the session ID cookie as HttpOnly and 'secure'

I suppose it depends on how you would implement this whole thing, but the liklihood is that you would run into a host of runtime issues tracking the changing session id's.

Would it help? Not really. You can spoof REMOTE_ADDR, and catching the session id before it changes is pretty straightforward: catch it and use it before the user makes another request.

The better idea would be to encrypt the cookie value(s), only connect via HTTPS, set the cookie lifetime to something very short/set session lifetime to something very short, set the cookies to HttpOnly (not accessible via JavaScript -- only part of the newer browsers though), and finally, use framework session management -- don't roll your own. :)