Correct way to manage sessions in PHP?

Question

I'm currently setting up an authentication system. My current layout is to get his email from the $_POST, md5 his password, and check the database against his email and his password. If it matches, I use session_start, and I start storing data in the $_SESSION variable, like so:

 $_SESSION['uid'] = $uid;  $_SESSION['first_name'] = $first_name; 

And on every page of the website, I would preform a simple check of

isset($_SESSION['uid']); 

if not, redirect to index page, if is, load the page.

Am I doing this correctly? Is this secure enough? How easy is it for someone to forge that data?

Someone told me that I should create a table, with the user's email, and his session-id and use that to manage things... I've become rather confused - how would this help?

Could someone clarify this? What is the correct way to manage authentication with PHP sessions?

Thanks.

Answer 1

Security update: as of 2017-10-23: The advice in this answer, while of historical significance, is completely insecure. One should never use md5 in hashing a password because it is so easily brute forced. See this answer about how to use the built-in password_* api to hash and verify passwords.

---

I've dealt with login/authentication systems earlier, and I find several shortcomings in this method:

• you "md5 his password, and check the database" -- this means that if a person has access to the database, he can make out who has the same passwords!

ADDENDUM (19 Sep 2015) * Look at this link. It explains all the basics, the approaches you could take, why you should take those approaches and also gives you sample PHP code. If it's too long to read, just go to the end, grab the code and get set!

BETTER APPROACH: to store md5 of username+password+email+salt in the database, salt being random, and stored together with the user's record.

• using the 'uid' directly in the session variables can be very risky. Consider this: my friend is logged on from my browser, and he leaves for a leak. I quickly check which cookies are set in his browser, and decipher his 'uid'. Now I own him!

BETTER APPROACH: to generate a random sessionid when the user logs in successfully, and store that session ID in the $_SESSION[] array. You will also need to associate the sessionid with his uid (using the database, or memcached). Advantages are:

1. You can even bind a sessionid to a particular IP so that the sessionid can't be abused even if it is captured
2. You can invalidate an older sessionid if the user logs on from another location. So if my friend logs in from his own computer, the sessionid on my computer becomes invalid automatically.

EDIT: I've always used cookies manually for my session handling stuff. This helps me integrate the javascript components of my web apps more easily. You may need the same in your apps, in the future.

Answer 2

There is nothing wrong with doing this

isset($_SESSION['uid']); 

The session data is not transmitted to the user, it's stored on the server (or wherever the session handler stores it). What is transmitted to the user is the session id which is just a random string generated by PHP, this can be stolen of course because it's sent to the user.

It should be clearly noted that randomly storing a string in the database and the users session and then using that to identify the user does not make the session any more secure, if the attacker gets the session they are still going to have compromised the user.

What we're discussing now is session hijacking, you may be thinking that you can just store the IP address in the session and check that with the IP coming from the request and be done with it. However it's often not that simple, I got burned with this recently when on a large web application we were storing a hash of the User Agent + IP address in the session and then checking that they matched on each occasion, for 99% of the users this worked fine. However, we started getting calls in from people who were finding that they were continually being logged out with no explanation. We put logging on the session hijacking checks to see what was going on and found that these people would come in on one IP and their session would continue on another, this wasn't a hijacking attempt however it was to do with how their proxy server worked, as a result we amended our session hijacking code to ascertain the class of the IP address and from there figure out the network portion of the IP address and store just those parts of the IP address, this is slightly less secure in that session hijacking could theoretically come from inside the same network but caused all our false positives to go away.