views:

113

answers:

3

(I think) I understand why session IDs should be rotated when the user logs in - this is one important step to prevent session fixation.

However, is there any advantage to randomly/periodically rotating session IDs?

This seems to only provide a false sense of security in my opinion. Assuming session IDs are not vulnerable to brute-force guessing and you only transmit the session ID in a cookie (not as part of URLs), then an attacker will have to access your cookie (most likely by snooping on your traffic) to get your session ID. Thus if the attacker gets one session ID, they'll probably be able to sniff the rotated session ID too - and thus randomly rotating has not enhanced security.

A: 

Web development isn't my thing, but is it possibly because the user logging in may be an attacker? For example, if I log in and get session ID 4, can I guess that session ID 5 will belong to some other user, modify my local cookie, and then act as that user?

Aidan Cully
That would be a possibility if session IDs were generated sequentially. However, good session ID generators generate random IDs for just this reason - so attackers cannot guess them.
David Underhill
+1  A: 

Sounds like a dumb idea overall.

It would totally screw up users if they hit the back button as the links on previous page would now include an out of date session id. You can also throw out any AJAX because each time a RPC is made to the server, all links/forms on the page require updating as they now have invalid values. If anything this is less secure because it means your application becomes more complicate and hass more chance to have a mistake in it.

If reasoning demands you "rotate" ids it probably means your ids are poorly generated, and that should be the thing that gets fixed. If snooping is a problem use SSL.

mP
I don't think this creates a problem with the back button. And I think you can workaround AJAX/near-simultaneous requests by only rotating the session ID every N requests, and retaining old ones for a short period. Of course, just because it doesn't screw those things up doesn't mean it is a good idea. I agree with you in that I don't think periodic session ID rotation is worthwhile either. I also agree that if snooping is problem then SSL is a must.
David Underhill
By not rotating/changing you have effectively stopped rotating. So what if your app is a single page and never changes. Your ajax on that page will eventually become older than the session id TLD.
mP
+4  A: 

If you're using session identifiers stored in cookies, session fixation is not an issue. I skimmed through the paper you pasted and I see things like using DNS and XSS to own the user, which obviously are much greater (not to mention, separate) issues than session fixation. If you have the session identifier (with an acceptable level of entropy) stored in a cookie, there is no sane reason to rotate it. The only reason to rotate it would be because it's guessable or vulnerable in some other way, in which case the user gets owned anyways.

Longpoke
I think rotating the session ID (SID) when logging in is necessary even if it is stored in a cookie. Consider this: The attacker browses the website on a shared computer and gets assigned a SID (but doesn't login). Then the attacker walks away. If the next user then logs in and the SID isn't rotated, then the attacker knows the SID and can use it to masquerade as the user which logged in. *This scenario is a little far-fetched* (hopefully the shared computer still has separate accounts), *but possible*.
David Underhill
What you said is a serious vulnerability (think kiosks). I was assuming the site assigns a new session ID on login. Of course, you should assign a new session id on login. And no, this attack is not farfetched at all.
Longpoke
Agreed. (note: my comment was mainly in response to the first sentence in your answer)
David Underhill