session_regenerate_id() vs session_id(randomString)

Question

What is the distinct difference between session_id($randomString) and session_regenerate_id()? Both seem to change session id:

session_regenerate_id() will replace the current session id with a new one, and keep the current session information.

session_id() is used to get or set the session id for the current session.

If I get it right, session_regenerate_id() creates a new session file and copies data over with an option to delete an old file; whilst session_id($randomString) just changes the session id in the existing file.

If so, what are the benefits of copying files? How is it better from preventing session fixation point of view?

This answer, nor any other I found, does not answer my question.

Answer 1

OK, so I did some testing to find the differences in the three different options (session_id($id) after session_start(), session_regenerate_id() and session_regenerate_id(true)). This is the result of what actually happens:

---

session_id($id) after session_start

Calling the session id function after session_start will change the session id. At the end of the page load, the current session contents will write a new session file. This will leave the old session file as well and it won't be updated with any changes. However, session_id doesn't send out a new session cookie. This is done by session_start, even when session_id is called before session_start. On the next page load, the old session id is passed and loaded with the same data as the start of the last page load (new session changes would have been saved to the new id).

---

session_regenerate_id() and session_regenerate_id(true)

session_regenerate_id() will create and change the session id, transferring the session to the new file and send out the cookie. Passing true as an argument will also delete the old session file, omitting the argument will leave it.

---

As far as session fixation, both session_id($id) and session_regenerate_id() would actually be worse as you are creating new sessions while leaving the old session files around to be hijacked. The only option that might help with fixation would be to call session_regenerate_id(true) passing the argument.

Answer 2

The session_id function will just change the session id and update the session cookie on the client. The session_regenerate_id function will act like the session_id one with the additional session migration on the server. In fact as you can read from the docs of the session_id function, it needs to be called before the session_start function, otherwise it may be lay you to a session loss.

Example:

Conditions:

• You're using file based session (php default)

Description:

• You start a new session for the current user, the generated session id is '1234abc' and the session save handler saves the session information in /tmp/sess_1234abc.
• The user will now leave your app
• The user comes back to your app and the session save handler retrieves the session id '1234abc' from the session cookie; then the session save handler will load the session data file (/tmp/sess_SESSID in this case /tmp/sess_1234abc)
• Now you change the session id to 'myTestSession' using the session_id function
• At this point the user session cookie gets updated
• The user leaves your app
• The user comes back to your app but the session save handler couldn't retrieve the session data, in fact it will look for the /tmp/sess_MyTestSession file but the session has not been changed by the session_id function so is still /tmp/sess_1234abc!

So if you want to prevent session fixation the way to go is definitely session_regenerate_id