Mitigate brute force attacks on login page

[eluser]novice32[/eluser]
Thanks guys for the feedback and suggestions. I'll have to research more the different options. I have working SaaS application and won't be able to easily integrate Community Auth. I'll look at leveraging some of its code. In the end, it will be a home grown solution.

Another thought that came to mind is showing a captcha after a certain number of failed attempts. The captcha would be based on ip. With captcha, I wouldn't need to lock accounts or anything of the sort.

Are there any good resources you could share regarding a captcha solution?

I'm thinking of blocking an IP and and displaying a captcha... say if there are more than 10 failed login requests / per IP.

Your thoughts?

[eluser]WanWizard[/eluser]
Not sure a captcha will protect you, it just means the attacker has to write a smarter script. You'll have to mitigate server side.

I mitigate this by adding a delay before a second attempt to login can be made. The first few (configurable) are delay free, after that the delay is added, and the more attempts are being made, the longer the delay is.

After a (configurable) number of attempts the source IP is blacklisted and the delay is reset, to avoid this being used as a DDOS (you don't want the legitimate users to be locked out of their own accounts).

[eluser]novice32[/eluser]
@WanWizard - how are you performing the delay (ie, php sleep(seconds)?

[eluser]skunkbad[/eluser]
I did a bunch of work to Community Auth in the last couple of days, and part of what I did was to add functionality that adds an IP to a deny list in an .htaccess file after 10 unsuccessful logins. Under normal circumstances, meaning a human that is trying to login, they would only be allowed to get to 5 attempts before they are locked from further attempts for 10 minutes. If for some reason they keep attempting to login, perhaps by script, then they may achieve 10 unsuccessful logins, and they will get 403 Forbidden errors until an Admin goes in and clears it, or a certain amount of time has passed. I haven't actually developed that last part yet, but I got to the point where the IP address is added to the htaccess file. The idea of denying somebody access by adding their IP to an htaccess file seems a little extreme, but it certainly handles the problem at the depth that I thought was reasonable for Community Auth, and reasonable for the majority of users. Yes, some people won't have an .htaccess file, so this functionality will be allowed to be turned off (but I haven't coded that up yet either). I'm hoping to have all of this done by next weekend.

[eluser]WanWizard[/eluser]
[quote author="novice32" date="1335122581"]@WanWizard - how are you performing the delay (ie, php sleep(seconds)? [/quote]
No, using a 'flood control' mechanism. So after a failed login, a new login will not be processed until "time() + delay" has passed.

[eluser]glassyflower[/eluser]
People get 3 tries on passwords on my servers and then they get locked out by the firewall for 20 minutes for the first offense and then 24 hours for the second if it occurs within a 24 hour period. I use scripts that constantly monitor the php and apache error logs (and other logs) for bad login attempts and other risky activity. It’s much better to block at the firewall level rather than the script level as they won’t even be able to get to the script (or anything else on the server) after being blocked by the firewall. If you block at the script level I can just hit you over and over with multiple attempts and still be able to slow your app/server down with processing the requests, even if they ultimately get rejected.
i think so.

[eluser]novice32[/eluser]
I would like to add some "extra" security to a public web form. Which is a better option? I know there are advanced spam bots, but thought to still ask.

OPTION 1) set a session value when the controller function is requested

Code:

$this->session->set_userdata('token',"some_constant_text");

Upon a form POST, I would confirm the session value:

Code:

if ($this->session->userdata('some_constant_text') == 'some_constant_text') {
return true;
} else {
return false;
}

Cookie values are encrypted.

OPTION 2) Pass a token value to hidden form field, and validate it upon return;
Controller:

Code:

$data['token'] = $this->input->ip_address();

View:

Code:

<?php echo form_hidden('token', $token); ?>

Controller Input Validation:

Code:

$token = $this->input->post('token');
$ip = $this->input->ip_address();
if ( $token == $ip) {
return true;
} else {
return false;
}

Let me know your thoughts.... maybe some of you will say both options??

[eluser]CroNiX[/eluser]
How is that different than CI's built in CSRF protection (when enabled)?

[eluser]novice32[/eluser]
I'm using CI 1.7.2, which doesn't support CSRF :-(. I'm not in position to easily update.