On successful authentcation, a web application issues a session cookie that is a constant length string of apparently random hex characters.


This session cookie is submitted for each HTTP request and the response contains a different value each time, meaning that this value is only ever used once. Any changes to this value will invalidate the session.

I usually see a session token values that is used many times for an entire auth session. In terms of the 'single use' arrangement described above, I see:


  • reduced risk of hijacked session as value is less likely to be valid when an attacker attempts use


  • increased computation resources required to generate non-random token each time
  • possible entropy drain of host OS from constant PRNG use

Are there any other considerations that I am missing here? Thanks

  • 1
    This effectively eliminates the entire purpose of a session. If you don't care about a session, just don't use it. If you don't know what a session does, you'd better figure it out before you mess with it.
    – Xander
    Commented Nov 13, 2018 at 4:58
  • Thanks, the application I am encountering exhibits this behaviour; it's probably not feasible to guess a token so it seems effective. Can you elaborate a bit more on your answer? Commented Nov 13, 2018 at 5:11

2 Answers 2


This solution would help to protect against a replay attack form a passive listener, but in if you were doing the session over HTTPS (as you always should), it would be hard to replay in any case.

One think I'd recommend you think about is what happens if the client doesn't receive one of the sessions for whatever reason. Do you accept any of the last 5? Do they have to reauthenticate?


This solution is in effect similar to that of a renewal timeout mechanism and has similar concerns:

Revocation Timing

If your previous session ID is immediately revoked there is a chance that your client has not yet received the new session ID before attempting to access some other resource with the old session. (For example your user might grow impatient and click on some other link while your request is still in process or simply your app is firing a lot of async calls).

One way to get around this is to allow a safety interval where it is still possible to use the old token for access. However this also means you'll have to keep the two sessions synchronized to avoid data loss on expiration of the old token.

Race Conditions

There is still a chance that an attacker could renew the session ID themselves with a valid session ID before a user does. If the attacker wins the race the user will find their session suddenly cut off.

Whether or not this is more or less likely with this solution will depend if you've also set an idle timeout (revoke if no activity after a certain period) and absolute timeout (revoke after a fixed time) for your session. If you don't have these set then your user might for example navigate to a page and leave it there.


There is also the question of whether or not renewal timeout is needed at all in preventing session hijack. Idle timeout and absolute timeout with a sensible expiration can already achieve similar results without extra server load. Also for preventing simple session theft it is sufficient to simply use SSL. All in all unless there are changes to the user's access rights/privilege level it seems a bit redundant to change the session ID.

reference: OWASP Session Management

  • After more testing, it turns out that previous tokens can be used while a session is active. One possibility is that the token is encrypted and contains information (such as a time stamp, user ID). Commented Nov 13, 2018 at 22:34

You must log in to answer this question.

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