Question

This is how I’m building a login system:

Login:

1. Check username and password supplied by user with the database.

2. If username and password is correct, store only user ID in session, something like:

   $_SESSION[‘userid’]=$userid;

3. If User has checked the option to stay logged in, then set 2 cookies, 1 with userID and other hashed string.

To check if user is logged in:

1. Check if Session exists, the user is logged. is it ok?
2. If session does not exist, check if both cookies, userID and hashed string exist.
3. If Both cookies exist, validate them.

As the Session is stored in the server, is it secure to store only userID ? Can a user pretend to be other user and store his userID in the session and log in as him?
Thanks.

Answer 1

Yes, this method is very insecure. I can sniff traffic, intercept your cookies, and your system will accept me as an authenticated user. You are making the assumption that if you get a cookie with a userid and the hashed string, then that user is the same person that originally authenticated to create the cookie. That is a poor assumption, because cookies travel in plain text (unless you encrypt them), so as long as I can grab a cookie, I can pretend be whoever sent that cookie, and your system doesn’t know any better.

Edit:

If you are going to use unencrypted cookies, why not just store the session_id in a database table? That way, at least someone that gets hold of a cookie won’t have a valid username. Create a sessions table, and when someone successfully authenticates add a row with their user_id and the session_id. Each time a page is loaded, check to see if the session_id in the cookie matches a row in the sessions table. If yes, you can assume the associated user_id is the authenticated user. This approach is just as secure as the one you suggested (i.e. not very), but it’s less complex and doesn’t give away valid usernames.