white_list

[chefmech]

I added a whitelist to bfstop. Would be nice, if you could include something like that to your plugin:

2 new functions,
1 new DB-table,
1 extension in function onUserLoginFailure

//-----------------------------------------------------------------------------------------------------
function isIPwhitelist($ipaddress)
{
    $sqlCheck = "SELECT COUNT(*) from #__bfstop_whitelistip where ipaddress='$ipaddress'";
    $this->db->setQuery($sqlCheck);
    $numRows = $this->db->loadResult();
    $this->checkDBError();
    return ($numRows > 0);
}   


public function onUserLogin($user, $options = array())
{
    //add IP to the whitelist

    $blockEnabled  = (bool)$this->params->get('blockEnabled');
    if (!$blockEnabled) {
        return true;
    }else{

        $ip = $this->getIPAddr();

        //IP not in whitelist already
        if (!$this->isIPwhitelist($ip)){

            $whitelistEntry = new stdClass();
            $whitelistEntry->ipaddress = $ip;
            $whitelistEntry->user = $user['username'];

            $this->db->insertObject('#__bfstop_whitelistip', $whitelistEntry);
            $this->checkDBError();      
        }

        return true;
    }
}   

public function onUserLoginFailure($user, $options=null)
{

    //Check whitelist                                
    if ($this->isIPwhitelist($this->getIPAddr())){        
        return true;
    }
              ............
//-----------------------------------------------------------------------------------------------------

[codeling]

Looks good, thanks; with your permission I will add that to the next version (0.9.11)?
This definitely has the possibility to improve the user experience. I haven't entirely thought through the security implications of this, so I will probably add it with an option to be disabled via the backend

[codeling]

Thought about it a bit more and found out that with the current implementation there seems to be one big security hole this would open:
Assumptions: User registration is enabled; and users want to attack special users, e.g. the admin user or another user with special permissions.
Now when somebody wants to do a brute force attack, all he as to do with the whitelist as above in place, is to register another user and log in with that account once; then he could try an arbitrary number of login attempts for a different user!

This specific problem might be fixed by checking the username as well, but my intuition at the moment is that for security it would be best not to have such special exclusion, but rather a block threshold which will make it very unlikely for "normal" users to be blocked.

Unless somebody raises compelling arguments for implementing such a whitelist, I will not include it.

[chefmech]

That's right, I only have few admins and disabled user registration...
I had the Problem, that one of the Admins was blocked several times. One option is, that you only use the whitelist for admins.

No worries if you dont add this feature, I did it for me and i just want to share the code in the open-source-mind

[jpeg729]

There is a compelling reason for per-user whitelisting: Protecting against distributed attacks.
Basically it would work like this.
Correct user logins from their whitelisted addresses are always allowed.
An aggressive throttle for any non-whitelisted user-ip combinations to limit any botnet attacks.
During throttling human users would be presented with either a form with a captcha or a link to email them a code that they could then use to accompany their login attempt.

Result:

• you can always log in from your own computer
• on a new computer you can always log in after a little annoyance.
• a bot can't just register to try other usernames
• distributed attacks are rendered infeasible

I can't see any other reasonable way of fighting distributed attacks.

More details here.
http://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure

[codeling]

Thanks for your detailed comment and the link! I've been thinking of methods to use against distributed attacks, and this seems to hit it pretty spot-on! I'll try to get it into one of the next versions...

[codeling]

rethinking this, captcha's would be a different issue, I'm not planning on impelenting these any time soon (as they would require a major addition, modifying the login page and such). The rest will be done as part of #76 .