Is it helpful to have a captcha on a login screen?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 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?

Answer 5

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)

Answer 6

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).

Answer 7

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.

Answer 8

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.

Answer 9

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.