0

My boss asked me how I would improve the login strategy they have implemented at the moment: introduce user, password and resolve a .NET captcha from the first attempt.

An auditor security team said that our web applications may be vulnerable to brute force attacks, so I propose them to carry out the following strategy:

  1. Let the users introduce incorrectly user and password 3 times.
  2. After the third failed attempt, the captcha must be also resolved.
  3. After another 3 failed attemps, the user will be temporaly locked out at IP level (a few minutes).

I proposed that because it will also improve a little bit the usability. A big part of our users are elderly people, and it is annoying for them to resolve the captcha every time they want to log in.

So, my question is: will it be safer to show the captcha from the beginning? Some time ago, a lot of websites used to show it after n failed attemps, but now they prefer to make sure the user is not a robot every time he wants to be authenticated. Is there any reason to really do that?

2

If brute forcing is your main worry you can just have it show up after 5 attempts or maybe even 10. If someone tried 5 variations of their password it sounds pretty reasonable to have a captcha pull up, even with elderly users.

When you are talking about brute forcing we could be talking about hundreds of attempts within a few seconds, so that would still help with mitigating that.

| improve this answer | |
2

IP blocking isn't a great idea; too many places use NAT and/or proxies to serve a large number of people (Internet cafes and other public-access or shared-access networks, businesses, residential complexes, Carrier-grade NAT for areas with very few allocated IPv4 addresses, etc.). This makes IP-based blocking a denial-of-service vector against everybody else using the same external IP address.

Using a CAPTCHA after N failed attempts (where N is usually in the range [1-5]) is sufficient for blocking brute-forcing attempts without risking DoS to your legitimate users.

| improve this answer | |
0

I'm hugely in favour of what you're doing. You can even make it 5 fails = CAPTCHAs, 10 fails = ban the ip or account for 1h (or force email recovery). Attackers frequently have access to multiple IPs (using proxies, tor, compromised machines, etc), so I don't really like blocking at the IP level.

But details aside, major sites do exactly this: Google, Facebook, and others allow a couple wrong guesses before showing a captcha. And I'm 100% in favour!

| improve this answer | |
  • I proposed that type of lockout because otherwise any user could block other user's account. What would think the legitimate user when he tries to log in and he sees his account has been blocked? – user3145085 May 18 '17 at 20:53
  • There are two options, and you can use both: make it a short lockout - an hour, or even a few minutes - or give them the option to unlock via an email. – Ron Bowes May 18 '17 at 20:55
0

Just implement a captcha and IP block after n number of attempts like you suggested. If you can do Google ReCaptcha, then that would be less complicated for the elderly end users and it would still stop bots effectively.

Ultimately the only way you'll truly detect a compromise is by monitoring account activity. Say the attacker socially engineered a user, then uses that credential to log in - they never hit one of your controls. Always assume your users can be socially engineered.

| improve this answer | |
0

You can learn a lot from the techniques typically used in fail2ban. E.g. Tar pit login attempts and delay response on each login attempt to make the use of automated tools slower. Particularly where this may be combined with trying multiple different logins and passwords.

Monitoring of your user accounts as has been mentioned and then taking actions based upon this.

E.g. Lock the user account

Depending on the application also consider using 2 factor auth by default for logins

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.