login system (sessions and cookies)

[Leni]

Hello,

I'm finishing a login script (half-way done) and I was wondering if this is a good way to go about it:

LOGIN:

1. User submits username+password (script checks lengths, valid characters and escapes these values).

2. Check if username and password match values on the database; if they don't match, display error.

3. Check if account is activated and not suspended.

4. Account is all OK, generate a random string (as $rand_id), hash it and store it on the database.

5. Set session variables (logged = "1", uid = $userid, rand_id = $rand_id).

6. Get user agent, hash it, store it as session variable.

7. Update login time on the database

8. If user requested automatic login, set a cookie (with the random id and the username).

9. Regenerate session id.

10. If user logged in from a page that required a login, send the user back to that page (location is stored in a session variable), if not, send the user to the control panel.

CHECKING IF THE USER IS LOGGED IN:

1. Check if $SESSION['logged'] == "1".
   

2. If session is set, check $_SESSION['uid'] & ['rand_id'] against database userid & rand_id. Check the session-stored user agent with the current user agent. If OK display content, if not, send user to login page.
   

3. If session is NOT set, check if autologin cookie is set (if it is NOT set, send user to login page).
   

4. If cookie is set, check database for matches against random id and username. If there's a match, generate new random id, store it in the database and set session variables/cookies. Display content.

LOGOUT:
I haven’t thought this one out yet, but unsetting the session values and destroying the session/cookies should be enough?

Is this OK? Am I doing something wrong, is there something that could be done in a better/more efficient way?

(I'm trying to get as much info as possible on this to avoid security problems after the login system is in place and in use by actual site users.)
Thanks for any help!

[radam]

Leni,

that sounds as though it will be ok for basic security. However, I do not think that your approach protectects against session hijacking. To protect against this, you can do one or both (pref. both) of the following:

1 - Check that the IPs between requests match. This will involve storing the users IP in the database at the start of the session, and comparing at each subsequent request. However, you should probably only check the first 24bits of the IP, as some ISPs use multiple proxys, so IPs can change, but it is normally limited to an 8bit subnet.

2 - On each request generate a random string. Store that string in a cookie variable (seperate to PHPs session handling), and in the database. For each request, compare the cookie's random string with the one in the database. The means that an attacker would have to intercept the session and take advantage before the user made another request.

I hope this helps you. Personally, I dont use PHP's built in session handling - I use a Session class which checks the user agent, IP, and random string for me - and then stores values for that session in the db.

[Leni]

Hello, thank you for your reply!

Regarding your two improvement suggestions, I'm a bit wary about using them for two reasons: one, this particular site gets a fair amount of people who seem to have anonymizers or are have peculiar internet connections that sometimes prevent them from properly accessing certain pages that need things like referrers and other checks to be retrieved (though these visitors are certainly a minority, I'm willing to try the IP check as you suggested it and hope for the best, I'm already hoping it works out for the User Agent check); two, I would like the login/authentication to work even if the user's browser can't accept cookies. The random string suggestion, I have seen it on a few tutorials and I like it, but a lot of people access the site from public computers (libraries, student dorms, etc.) and sometimes they can't accept cookies. Is there another way to implement such a check without resorting to cookies? Or should I implement this and just tell the user that cookies are strictly needed? (I'd rather not do this, but securing the overall users information/accounts is probably of a higher priority?).

I hope I explained myself sufficiently well. Thanks again for your help, at this point I couldn't really get any input on this from anyone else (by now I was wondering a bit if this was a completely inane question 🙂 )

[radam]

Leni,

they are good points, and in some cases you simply cannot assume that cookies will be enabled. Another, more difficult, option would be to pass the data in the query string rather than using a cookie, but this would require each internal link to be dynamically generated. However, if this is a high volume site it may not be practical to be reading and updating the database for each request.

[Leni]

Hello again,

I think I've seen some sites doing that (like amazon, which always appends that ID), but maybe the cookies option will be best. I'll just have to warn users that they (unfortunately) need cookies if they want to use the user account features!

Thanks again for your input, I will add your suggestions and hopefully the login system will be safer! 🙂