I am wondering what the risks are of storing the userid in a session?
then simply doing a
if(isset($_SESSION['user_id'])){
login_user($_SESSION['user_id]);
}
Are sessions encrypted enough that we wont have to worry about hashing them? What are the chances of someone being able to change their ID?
The session is by default stored in /tmp as a file. It is not viewable by the end user unless you have security issues such as directory traversal vulnerabilities.
The only portion the client sees is the unique hash stored in a cookie which maps to the relevant session on the server.
Most applications use $_SESSION as you are. If there where a wide spread weakness then major projects would be doing things differently.
Storing a user id in $_SESSION is a reasonably common practice.
Your alternative could be to store the session information (including current user id) in a table using the session_id() in some form, as the key.
Session information is stored as plain text.
Dependant on your setup, the session location should be safe on a properly setup server. It is possible to change the location with session_save_path() which will overcome potential location issues.
If some one can access your session, he can, probably, access much much more. I would not hash it and also make sure it does not get to the client
I would advise against adding only the user id to the session. For example:
1: Create an account in one browser and log in. Then leave that browser open and go to another computer.
2: Log into the same account and delete it. Now make a new account with a different password (with the same username, if that is used as the id).
3: Go back to your other computer and do stuff. You will find that you could quite possibly now be using the account made on the other computer.
Basically, since the session stores the id this may not necessarily still belong to the same person depending on iff accounts have changed etc. And if no password is required (since you already went though that process when you owned the account) then it is similar to breaking in.
So this seems to only have a chance of working if, when you delete user accounts from the database, numeric ids can be reused (about 2% of the systems I have seen do this). Or if the user id is the username (about 20% I have seen do this).
So I would instead suggest adding the userid and the password hash (i.e md5, sha1) to the session and obtain the user information using both of them each time.
