Does regenerating the session ID on each request mitigate the probability of a session hijack enough to be worth implementing?

I would imagine combining a check for REMOTE_ADDR vs the REMOTE_ADDR stored in the session variables, along with a 30 minute inactivity timeout and a constantly changing session id should mitigate the risk to an acceptable level.

Additionally, are there any other concerns with regenerating a session id? Do I need to explicitly destroy the old session for each new regeneration?

Finally, would regenerating the session id on every request become too resource intensive on a large deployment to justify vs the security advantages?

  • Removed the PHP tag, since this question is applicable regardless of the implementation language.
    – AviD
    Commented Dec 20, 2010 at 17:57

4 Answers 4


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'
  • 2
    +1, except for one very important detail : random and unguessable tokens does not include GUIDs. GUID is inherently NOT secure for session ids. Please please change that...
    – AviD
    Commented Dec 20, 2010 at 18:13
  • True, updated although some would argue GUIDs are good enough given expiration and other factors affecting the session.
    – Weber
    Commented Dec 20, 2010 at 19:59
  • 2
    +1: EXCEPT - having a session established BEFORE authentication is not only critical to the operation of a lot of sites, it also makes implementing a lot of security controls much easier - but you should regenerate the id at authentication.
    – symcbean
    Commented Dec 21, 2010 at 10:26
  • 1
    Excuse, what do you mean exactly with "expire session IDs frequently": regenerate the ID or destroy the session? Commented Jul 4, 2013 at 20:32

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. :)

  • 1
    oo, good point - +1 just for the use framework session management -- don't roll your own
    – AviD
    Commented Dec 25, 2010 at 19:40

You should make sure your session expires and tokens are of course reliable and randomly generated.

However, from all these answers, I think the strongest point is to use SSL - but for the entire session.

Even if you login via SSL, and use normal http from then on, regenerating sessions from each subsequent request, and do all the good things mentioned above, there is really no way to guarantee that a user's session cannot be hijacked in some way. You really need to ensure that the transport of the entire session prevents eavesdropping and hijacking - which SSL was designed for.

The use of remote addresses is also pretty moot when it comes to NATed firewalls.

If you then need to go one step further in ensuring that a particular client's machine is the only machine that could login, you could issue a client certificate, which the user would load into their browser, and the server would request this during the SSL negotiation.


The best one I have seen in common usage regenerates the session identifier after secure login, and associates the identifier with the client machine. The application's security wrapper checks for concurrent logins (disallowing a new one until the old one has finished and ID expired) expires the ID on browser close or logout and also has a fairly short expiry time (10 minutes)

In conjunction with the other security features it was appropriate for the purpose (an online consumer banking application) without overloading the system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .