Kill Active Session if User Is Banned

Question

I have set up a login system that checks a mysql db validating username,hashed password, and a banned column (0 means not banned and is the default value, 1 means banned). if there banned they obviously cannot loggin.

The problem is i'm new to php and having a hell of a time trying to figure out how to log out a user who is currently logged in. As it stands now my cookie will last for 2weeks, and even if i ban a user, their session will stay active thus they will have acess for 2weeks or less.

How can i force a user to reauthenticate, without penalizing the masses.

Answer 1

If you are storing the session data in a database, delete the row with their session information. Or, delete the file if using files. Then next page load, the login system shouldnt be able to verify their login information (since there's no info for that session), and prompt them to re-login.

Answer 2

maybe you want to store the sessions in another table and delete it when you ban the user.

you know. check the table every time the user load a session and if the user isnt there. delete the cookie and destroy the session (sending him to the index of your site)

Answer 3

You can store the userID in the session and on each request, you check if he's banned (SQL query). If true, you destroy his session so he's forced to reauthenticate. Which fails of course because he's banned.

Answer 4

Your server knows what cookie is associated with each user. Why not just delete that cookie from its "current sessions" table?

If the cookie is just "username, who is logged in", you have a real problem, because instead of a magic number, the cookie contains real information, and it becomes trivial to forge. Then a malicious user could simply create a cookie saying "I am [admin], and I am logged in", and that's obviously a much larger problem. So if you can't just delete the session cookie from the "known cookies" table to solve this problem, you have a bigger problem to worry about.

Answer 5

If you are doing your authentication system completely on your own (kudos on that, BTW) you merely need to unset the session value that contains their authenticated status. So, if you used:

<?php
session_start();
if(isset($_SESSION['isloggedin']) && isBannedUser())
{
    session_unset(); 
    session_destroy();
} 
?>

The pseudo-code above calls to a fictitious function called isBannedUser() to determine if they are banned or not. If they are, in my example above I call session_unset() to unset all values stored within the $_SESSION and then session_destroy() to completely close the session. Some would probably argue that you may not need to unset if you're destroying, but I have just gotten into the habit of cleaning up all variables and values that I make in code.

This should be in every page so that you check if they're banned as frequently as possible. With the $_SESSION destroyed the user is, effectively, kicked out of any part of your website that requires authentication. You will need to implement supporting code in your login workflow that keeps a banned user from logging back in.

Hope this is helpful.

Answer 6

On a file-based sessions system, maintain a counter somewhere which triggers a periodic check of the database for updates, something like:

<?php
    session_start();
    $_SESSION['hits_since_last_verification']++;

    if ($_SESSION['hits_since_last_verification'] > 100) {
       $banished = ... // get banishment flag from database
       if ($banished) {
           $_SESSION['loggedIn'] = FALSE;
       }
    }
?>

and then decide how long you'd like a banned user to be allowed to continue poking around the site until the session data is refreshed and they get booted.

Another option is an external script which runs through the session storage directory, loads each in turn, checks if the user's banned, and updates the session file as appropriate. But this would be painful on even a moderately busy system as you open/unserialize/check banishment/update/reserialize potentially thousands of session files every X minutes.