28

I introduced recaptcha to the login screen of a system.

My goal was all about security things like dictionary/bots attacks or other thing of that type.

The users now hate it, Some did not even understand it and I had to remove it.

When I look around, I don't see many systems with that on the login screen, most of the times on other forms like contact us or sometimes like in stack exchange when you want to post.

It made me wonder is it a good idea to have it on the login screen?

  • 12
    I think you've answered your own question: The users now hate it, Some did not even understand it and I had to remove it. If you need a captcha put it when a user is doing something (e.g. posting a message, transferring money) rather than just signing in. – Eborbob Jul 14 '15 at 15:57
  • As a point of information, Register 365 have a CAPTCHA on their control panel login, so this is not unknown. (It's easy to bypass: just log in on the main site instead, then go to the control panel, so it's just pointless and annoying, but still, it's there.) – TRiG Jul 14 '15 at 17:59
  • 14
    If your goal is to stop dictionary and bot attacks, just add a delay after a failed login: 1 second, 2 seconds, 4, 8, 16, 32, and so on. A human who mistypes his password won't care about a 1, 2, or even 4 second delay. A bot will be pissed! – bishop Jul 14 '15 at 19:33
  • 1
    @bishop What do you base the delay on? The username leads to a trivial DoS attack and IPs don't work so well either when faced with a botnet which consists of many zombies. – CodesInChaos Jul 15 '15 at 10:32
  • 1
    @CodesInChaos Not username. Typically I configure my IDS to throttle by IP on repeated hits to login and reset routes. This has worked for all attacks to date. Sure if there was a zombie net with 100k nodes, they could try 600k passwords in 60s with this back-off, but for a high value site I might use a 500% exponential back-off: 1, 6, 36, etc. At any rate, this shouldn't be the only technique: mandatory 2FA or even 2FA informed by login failures would be A Good Thing. – bishop Jul 15 '15 at 11:14
45

The way I've seen some large systems do it is to only require a captcha after sequential failed login attempts (ie: reset the count after a valid login). If you are worried about automated cracking, you could put the captcha at some high number of failures like 20, 50, 100 failed attempts. Almost no legitimate user will see the captcha, but an automated attack will get hit by it.

Is it worth it to add this complexity? Security and UX are trade-offs. You need to find the correct trade-off for your risk profile.

  • 5
    That's mostly correct. The distributed attack across multiple logins will not get hit by it unless they fail N times for each login. If you are worried that a given account can get cracked in under N tries, you need to lower N. – rox0r Jul 14 '15 at 16:17
  • 3
    Although if only automated attacks ever see your captcha, then you might as well just ban them, instead of giving them a captcha. – immibis Jul 14 '15 at 19:28
  • 13
    @immibis: It may be difficult to distinguish automated attacks from legitimate users whose accounts are being targeted by a denial-of-service attack. If Fred's account is being attacked, requiring Fred to answer a captcha may be much less of a bother than being locked out altogether. – supercat Jul 14 '15 at 20:36
  • 2
    @Cthulhu the OP can collate the login attempts across accounts and client footprint (ip, etc). – Mindwin Jul 14 '15 at 20:41
  • 3
    @supercat I was thinking of banning the IP address, rather than the user. (Also, make it a temporary ban; automatic permanent bans are a recipe for disaster) – immibis Jul 14 '15 at 21:47
6

A captcha on a login screen makes no sense. I'm not surprised your users hated it. The purpose of captcha fields on forms is to prevent them being submitted by bots. A bot should not be able to login through your login screen, as it should not have valid credentials. If a bot can guess valid credentials, then you need to increase password strength.

5

The users now hate it, Some did not even understand it and I had to remove it.

This is where you'll have to make the decision between usability and security. Altough it is useful to have a captcha on your login pages, it's incredibly user unfriendly.

My best tip would to log every invalid login attempt to a database, and before authenticating the user, check if that IP has tried logging in X amount of times within the past hour.

You could also add some form of Cross Site Request Forgery system to every login page. This means that at every login attempt a hidden field with a token will be generated, meaning that an attacker would have to make two requests to try to log in.

4

Adding a Captcha or ReCaptcha is not a solution, it is merely an obstacle for both hackers and users.

I have very good vision with my glasses and sometimes I can barely make out the image text. I would imagine that someone in denial about their vision is going to be infuriated.

Everything you implement needs to have a specific purpose or else you just end up throwing pies in the sky with poo filling and these pies eventually land directly on your users.

Here is some food for thought:

1

Problem

User accounts are getting hacked due to automated brute force attempts

Solution

Accounts are now locked after 3 failed logins

2

Problem

All user accounts have been revealed and a bot is now trying to brute force all accounts

All accounts get locked within a matter of seconds due to 3 failed logins

Solutions? Plentiful, but did we even need to get to this step? Is this currently an issue?

  • 4
    Locking accounts after three attempts makes denial-of-service attacks very easy. Requiring that accounts with multiple incorrect attempts submit to a captcha would mean that someone who wanted to inconvenience someone else by making bogus login attempts on their account could do so, but the inconvenience would be limited to that posed by the captcha. – supercat Jul 14 '15 at 20:38
4

Another way of attacking this might be to install a "honeypot". This is an ordinary input field which is included in the HTML together with the login fields (username, password), but this extra field is hidden using CSS.

Typically, bots will try to enter text in all the fields shown in the HTML, so in PHP I checked that if the honeypot field were not empty - I would ban that IP.

(This was for a homepage for a skydiving club with a tiny admin feature to update dates when we are going to jump etc. I would not recommend this for sensitive applications)

  • Automatically banning IP's might not be the best approach, as users who cannot load your CSS or users who are simply joking around will get instantly banned. – Hugo Zink Sep 28 '15 at 14:33
  • It is correct that it has it weaknesses. However, due to the small user base for the particular site I made this for I found it OK. – fluxmodel Sep 29 '15 at 12:08
3

CAPTCHA systems are there to differentiate between automated bots and real users. Unfortunately, as you've noted, they aren't very convenient (in particular for disabled users).

Whether it's "a good idea" or not depends on your use case, really, although they aren't very efficient with user logins: they are not very useful to prevent password guessing attacks and implementing a rate limiter in the application is more convenient to the user while implementing a TOTP PIN provides better security.

Having some form of "proof of work" from your client might still be a very good idea if you're going to spend server resources for them and if these resources are limited. A typical use case for such query are system that will perform work for anonymous users (for instance, a web-based WHOIS application could use that to preserve resources).

3

Think for a moment about what your captcha is trying to accomplish. Here is the goal I can think of:

  • Prevent a large-scale automated attack from breaking into weak accounts

Here's a way to do that which will probably make your users happier:

  • If a computer successfully logs in (as Bob), set a cookie on that computer so the server knows that computer gets 5 free attempts to log into Bob's account without needing the capcha.

  • If the computer trying to log in is from Bob's last known ip, give that ip 5 free attempts to log into Bob's account without needing the capcha.

The idea here is that mass password guessing usually happens from computers or ips that have not legitimately logged into the account.

This can probably be improved by combining it with ideas from other answers where you give a few "free tries" to accounts or ips.

  • 1
    No need to include a captcha field after the 5 login attempts, simply lock out the user for a period of time. All sites should include some kind of password recovery feature, so it should never be necessary for users to keep randomly trying combinations. – user1751825 Jul 21 '15 at 23:51
2

Adding a captcha after 10 or 100 failed attempts it useless, as most current bots have a deathbycaptcha account, and the API for dbc is really easy to use. So, showing a captcha every second time is a good thing, I think.

0

To prevent brute force attacks, you would be better to do the following.

1) Ensure that passwords are complex enough. If given the chance a lot of users will use extremely simple passwords, like their name etc. Passwords should be at least 8 characters, and should include numbers, letters, and mixed case.

2) Lock-out IP's after 5 failed login attempts.

It may be worthwhile adding a captcha field to the password recovery screen. Make sure you include enough text to explain to users how it works.

  • Locking out IPs can be very problematic for customers if they share an IP (corporate users, etc.) – schroeder Jul 22 '15 at 15:34
  • Yes, locking out IP's can be problematic, but it's unfortunately a necessity to maintain the security of a website. The lockout period need not be very long. Even locking out for 15 minutes will significantly hamper brute force attacks. – user1751825 Jul 24 '15 at 0:58

protected by AviD Jul 15 '15 at 17:18

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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