Effects of new random Session token for each HTTP Request

Question

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

2E5F0FE4B7FCAB78CD967B46AB32915CCBFDC85316FAFB9174BDC4A3745339D8AD9C1D70A8EDD3D4F06107F3B1A67E85AEB1CB04F563818BC5D029D9E956652ED0F8F93E7A7EFD1E2E59DF1D378424964541E2C9B8A41436D0092A4114FBC4FA702A94C5090C34D97A3310F88CD3E9BDC8553230343BB1E4641F848102DF9B96AA81D6407273F774CFBD3E3FD68CAF84654B21E177A36DE7FB09EFC5A50A5253E1B5F5D6C5082A01D756CC68680FE1FBCA64CD72F1D6B1865C6FFC4B6BB8DE2C2B510731103F18DDA2289515F604632A26BD68B0E03647B854243EAFD7264B0765F45279BD6735E26D58DF720D5B9061EF316730

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:

Benefits

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

Disadvantages

• 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

Answer 1

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?

Answer 2

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.

Necessity

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