On an intranet a login is generally disabled after a very small number of failed logins.

But a public email service like Gmail can't do the same, otherwise pranksters would just be continuously locking people out.

Unlike brute forcing a password file that you have locally, hitting a specific account on a remote service like Gmail involves significant network latency - thus severly limiting the speed of a brute force approach.

And the service can introduce artificial delays, e.g. wait a few seconds no matter what before rejecting or accepting a login.

And it can increase the delay per IP address from which a failed login attempt has occurred.

But you can only go so far with delays before they themselves facilitate DoS attacks - if the valid user comes through a proxy, anyone else coming through the same proxy can up the login delay for that user with failed login attempts. So the delay can only be increased so far.

But even a 5 second delay, which would only mildly annoy a human, would thwart brute forcing from a single machine.

But what about a botnet? The largest have several hundred thousand machines.

If all make just a few attempts this means the victim's password just has to be in e.g. the commonest 10 thousand.

I've seen old analysis from 2011 that suggests 30% of user passwords fall into the commonest 10 thousand.

So you've got a 1 in 3 chance of cracking the given account.

But maybe:

  • Botnet time is too valuable to be used even for a short time to crack an individual account.
  • The rise of two factor authentication and password management systems make high value targets harder to hit.
  • Services like Gmail may actively look out for users who are subject to frequent hacking attempts, e.g. celebrities, and ensure they use two factor authentication.
  • High value users who are likely victims of such a coordinated attack have probably already been hacked once and have learnt their lesson - so the success chances of a botnet attack are too low to warrant it.
  • Enforcement of rules on password complexity have changed the percentages I've quoted.

Sorry if you feel this is a repeat of existing questions. @woliveirajr suggests in this answer that you should introduce a CAPTCHA after a few failed attempts.

If you don't do this on a per IP address then some users (celebrities etc.) must be filling in CAPTCHAs all the time! If you do it on a per IP address then you still get a lot of tries (see above) which cover a significant percentage of the commonest passwords.

Does Gmail or anyone else do this, i.e. require CAPTCHA's after several failed login attempts?

A number of answers on this popular question mention locking people out after a number of failed attempts, but as noted above I think you can only really do this on say a company intranet - not on something like Gmail where it would immediately be used for DoS.

  • This article points out how stats on the commonest password used may be inaccurate. arstechnica.com/security/2015/01/… It may not be that easy after all if around 1% of users use the commonest passwords Feb 2, 2015 at 14:49

1 Answer 1


Gmail requires CAPTCHA solving when it detects suspicious behavior for an account, even if the requests originate from several IPs.

There is always a balance to be set between user experience and user security. If a celebrity uses Gmail, she'd rather enter a CAPTCHA each time than having her emails publicly disclosed. Moreover, even if not yet "default on", 2 Factor Authentication should be used for any sensitive accounts, because it greatly decreases the risk of the account being compromised.

In my opinion, delays of any kind should not be used for web application, because they only add to user frustration and also help in building DoS attacks.

You must log in to answer this question.

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