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?

  • 15
    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
    Commented Jul 14, 2015 at 15:57
  • 18
    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
    Commented Jul 14, 2015 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. Commented Jul 15, 2015 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
    Commented Jul 15, 2015 at 11:14
  • 1
    What's wrong with captchas? They seem to work fine.
    – munchkin
    Commented Jul 22, 2015 at 7:42

9 Answers 9


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. Commented Jul 14, 2015 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. Commented Jul 14, 2015 at 19:28
  • 14
    @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
    Commented Jul 14, 2015 at 20:36
  • 2
    @Cthulhu the OP can collate the login attempts across accounts and client footprint (ip, etc). Commented Jul 14, 2015 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) Commented Jul 14, 2015 at 21:47

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.

  • There is a purpose of using a captcha token in login forms - to increase security against credential stuffing attacks. A botnet with millions of valid leaked emails/passwords is among the worst dreams of an API owner.
    – zerefel
    Commented Sep 15, 2023 at 21:31
  • 1
    With invisible captcha options available it now makes sense. It didn't 7 years ago. The op was clearly using one of those horrible distorted code types. I still maintain that they are horrible for usability. Commented Sep 16, 2023 at 22:12

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.

  • Blocking by IP is tricky thing. What about users behind CGNAT? Not all IPs are static.
    – Jeffz
    Commented Oct 15, 2020 at 19:56

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:



User accounts are getting hacked due to automated brute force attempts


Accounts are now locked after 3 failed logins



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?

  • 5
    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
    Commented Jul 14, 2015 at 20:38
  • "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.". How do you know you're not in denial? ๐Ÿ˜‰๐Ÿ˜‰
    – dewd
    Commented Mar 11, 2022 at 22:27

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
    Commented Sep 28, 2015 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
    Commented Sep 29, 2015 at 12:08

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


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. Commented Jul 21, 2015 at 23:51

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.


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
    Commented Jul 22, 2015 at 15:34
  • 1
    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. Commented Jul 24, 2015 at 0:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .