0

I like to have my sites keep you logged in if you're active, but log you out if you've been inactive for a certain amount of time (usually a day, but it depends on the exact project).

To this end, I've been doing this:

setcookie(session_name(),session_id(),...);

I just discovered this function: session_regenerate_id()

With this, it seems like I can just replace my setcookie code with:

session_regenerate_id(true);

If I understand correctly, this will renew the session with its initial cookie values (path, domain, etc.) and its full expiry time.

Would I be correct in thinking that, in a way, this provides additional security by making it significantly harder to steal a session cookie? (since, after all, the session ID would only be used once before being regenerated).

Essentially, this would end up having the server send a token saying "in your next request, use this ID"...

Is my understanding correct? What would be the downsides (if any) of using such a system?

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592

3 Answers3

0

The downside would be the fact that for each session, PHP creates a new file. When you rengenerate your session id, the old file will be deleted and a new one is created. It could cause big problems if your system will have lots of users (lots of disk writes).

There are quite a few ways of improving the security of your session data, but it's important to remember that you should avoid keeping sensitive information in sessions.

Relu Motica
  • 106
  • 1
  • I use memcache for my session handler. I suppose I should have specified in the question... How does this new information affect your answer? – Niet the Dark Absol Feb 04 '14 at 12:54
  • Well, that changes things :). You are working with memory, not with the hard drive, so speed is not an issue. And as a bonus, you won't have any problems with session handling if you ever need to scale your system across multiple web servers. – Relu Motica Feb 05 '14 at 09:37
0

If you are using sessions with cookies (which is the default), the default expiry time in php.ini is set to 0, meaning that the session is destroyed when the user closes the window. If you want to set an expiry time you have two options: change the value in php.ini or add the setcookie function.

The session_regenerate_id function does not interfere with whether expiry time has been set. Its purpose is to destroy the old session, assign the user a new one and silmutaneously preserve the $_SESSION variables. (An optional boolean argument may be given to delete the old session cookie).

Unless you use SSL the cookies are sent in plain text and therefore, one could easily steal a session were he capable of "sniffing" your packets. On the other hand, regenerating a user's session every now and then will make it quite more difficult for the attacker to impersonate the actual user.

Slinky Sloth
  • 301
  • 2
  • 5
  • If I don't regenerate with every request, someone with a sniffer could hijack the session, then load pages until they happen to get a regenerated ID. At this point, the real user would appear to be logged out, and the attacker would have full control... – Niet the Dark Absol Feb 04 '14 at 12:55
  • You're right, if regenerations occur periodically what you mention is possible. To prevent such occasions I suggest you used IP and user-agent verification methods for logged in users, and most importantly SSL. – Slinky Sloth Feb 04 '14 at 13:14
  • Hmm... I had IP verification in the past, but then I went to Sussex University where every request is routed from a set of IPs at random XD User Agent verification may help, but if someone has access to the cookies then they have access to the User-Agent header too. – Niet the Dark Absol Feb 04 '14 at 13:21
  • Indeed user-agent may not help. As far as IPs are concerned, although there are some facilities that use this random IP system, they're not the typical of the average user. So, without doubt there is a trade-off in IP verification usage. If you want to include this minority of users and at the same time ensure that an additional layer of security is integrated, opt for SSL. It's the last thing for me left to recommend. – Slinky Sloth Feb 04 '14 at 13:46
0

Yes, your understanding is correct. session_regenerate_id() helps against Session Fixation. https://stackoverflow.com/a/5081453/137259 explains it very nicely.

I can't think of any downsides if it's used properly, when the session state changes (ie user logs in or is elevated to a new access level), and if its bool param is set to true to delete the old session file. Disk I/O could be an issue like @Relu discusses in his answer, but then session_regenerate_id() shouldn't be used too frequently.

Community
  • 1
  • 1
Fanis Hatzidakis
  • 5,282
  • 1
  • 33
  • 36
  • I'm using memcache as the save handler. I don't think disk I/O is an issue here? – Niet the Dark Absol Feb 04 '14 at 12:54
  • Right, it won't be an issue for a session handler that doesn't use the disk. Frankly I don't expect it to be much of an issue for the (default) disk session storage - I haven't ran any numbers on this though. – Fanis Hatzidakis Feb 06 '14 at 12:05