Security with PHP Sessions
Session security risks come from three different possibilities:
- Prediction
- Capture
- Fixation
Prediction would mean that someone that's not the user for whom the session was created guessed their session ID. The chances of that happening are almost 0, although they do grow as more users use the site simultaneously.
With your code, you would make that risk even lower because it would only work if the attacker shared the user agent and the ip of the predicted session. But the difference is trivial in this case.
Fixation would mean that an attacker can create a session and then force another user into using their session. In this case it would depend: If the attacker knows that you are doing it and they fake the user agent and ip of the client, they could fixate the session. Or if they share ip and user agent.
And finally we have session hijacking, probably the most common method of the three. In this case an attacker would somehow gain access to the session id of a valid logged in user, and then use it to log in to their account. As with the previous method, this would only work for them if they know that you are checking the ip and user agent, and faked the same ones as the user. The technique you are using is not unique, and some attackers might fake them just in case.
That being said, is it secure? Yes and no
If you are obsessed with security, the answer is always the same: Use SSL
Unless your code is open source, almost anything you do that changes the behavior of the php sessions will be secure enough.
The only exception to that would be really popular sites that will attract the attention of hackers.
There is some very good documentation on this topic available:
I'm not a security expert. However, I humbly doubt that your security enforcements will bring substantial benefits.
If there's one who can steal the session ID of your users, for example by eavesdropping an unencrypted wireless network, I bet he can steal also the username and password your users send to your server when they authenticate. Once he has the access credentials, the attacker can login the day after, or a week after, and will have his "safe" - and 100% valid - session to play with.
I believe there is no session security without channel security. If you use SSL, you ensure that the session ID is sent only via cookies (you're already doing it) and your sessions expire soon, I believe you are reasonably safe, and safer than making these enforcement on an insecure channel.
Firstly, you have a mistake in the session regenerate code. The following if will always evaluate to true:
if ($rand != 1 || $rand != 3 || $rand != 5)If $rand is not 1, it returns true. If $rand is 1, then it's not three, and it returns true. You probably meant to use an and here.
Secondly, you don't need to MD5 the user_ip, or the user_agent strings. If someone can access the session data on your server directly, you're so deep in it that hashing that data won't save you.
CLARIFICATION: As SDC and crush point out in the comments, MD5 is good for hashing passwords if you hash it with a salt. This means that your user's passwords are generally still secure, even if a SQL Injection attack succeeds and your database is exposed to the world. However, if your server is compromised, and the salt is compromised, then it becomes possible to generate a set of known hashes, and to attempt a reverse lookup of a specific password. Bottom line? Hash your user passwords, with a salt.
Thirdly, most security holes don't come from spoofing sessions. They come from poor input checking. A book like Essential PHP Security should be a good introduction to the kind of input checking you should do in a PHP project. Failing that, at least read the security section of the PHP Manual. Pay attention to the SQL Injection bit. It's cool!
Finally, I fully agree with the other poster that you should use SSL to secure communication to your website.