I track members who have logged in with a session variable $_SESSION[‘memberid’] which corresponds to the primary key of table called members in my mysql database. So when a user logs in, their memberid is stored as a session variable. The id is in the same row as their username, email, password, and so on in the database, and it also serves to track their behavior in other tables, such as how many times they have logged in. I have seen some use another session variable that doesn’t correspond to a database column, like $_SESSION[‘loggedIn’], instead of the user’s id $_SESSION[‘memberid’].
I use the contents of memberid for fairly sensitive things. (The contents of $_SESSION[‘memberid’] are used to display that user’s profile, for example.)
Are there any security risks to my approach? I was concerned because I looked at the PHPSESSID cookie, and although it seems encrypted somehow (it certainly doesn’t immediately show $_SESSION[‘memberid’], at least) I was afraid that it might be hidden in the cookie somewhere, or that someone just might bruteforce the cookie in order to log in. I am concerned that it might be possible to bruteforce into a known memberid.
When a user logs in you assign a value to a session variable. That value can be anything and the session variable can be called anything.
For example:
In a typical users table I will have a unique userId and first name and last name stored in 3 columns. When a user logs in with a valid username/password I will assign a session variable something like $_SESSION[‘mySessVar’] = ‘qwerty’ and then at the top of every page I check for the existence of and correct value in $_SESSION[‘mySessVar’]. If the session variable is not set or has an incorrect value, then the user is not logged in.
What I also often do when a user successfully logs in is set their first name from the db table in a session variable as well. Then at the top of each page, if the user is legitimately logged in I would display a welcome message along these lines:
If you are doing sensitive things with the member, then perhaps force them to revalidate before they can do such things.
Just make them relogin and if it checks out, use session_regenerate_id(true) to create a new session for them and delete the old one. This will also help against session hijacking.
Basically if an attacker gets a-hold of someone’s cookie, it’s hard to be sure who that person really is. You could use user agent checks, or ip checks (but some people’s ip changes very frequently) but these are not 100% definitive.
So it’s best to just reauthenticate before doing anything potentially harmful.
Thanks webdev and scootstah. I do the same thing, webdev. I also plan to force re-authentication before sensitive areas can be accessed.
This eases my mind a little. I was thinking that this session tracking stuff was a bit too easy and so I was probably committing some sort of massive security error.
Long as you dont start sending the sensitive data via COOKIE, you’re fine. (SESSID is an automatically generated value stored by session_start() and is considered ‘secure’ (entropicly secure, anyway), though as stated above, if you’re concerned, have the user revalidate their login before doing anything account-threatening)
As others have pointed out, sessions are typically more secure then cookies. You just need to make sure you don’t store anything sensitive in them. Also it’s good practise to use session_regenerate after any important changes to a user e.g. when a user logs in. For more information on sessions and security check out this page http://phpsec.org/projects/guide/4.html hope it helps.