70

Some websites lock out a user after a series of incorrect password attempts for example for 15 minutes. If a malicious actor knows this, can they deliberately try logging in with incorrect passwords every 15 minutes to prevent the real person from logging in? Is this a real threat and if so how can websites protect against it?

yeti
  • 865
  • 1
  • 6
  • 8
  • I saw a website that would lock the user out until they clicked a link in their email. – Jon Apr 06 '17 at 00:57
  • 7
    When I was in high school, the NT domain would lock you out for 15-20 minutes after 3-5 incorrect attempts, and usernames were based on people's real names. If you knew how to enter the keystrokes to log out (Ctrl-Alt-Del, L, Enter), you could lock someone's account on your own computer, walk up behind him, reach over, and log him out before he could react. – chrylis -cautiouslyoptimistic- Apr 06 '17 at 07:40
  • 15
    Most online banking sites I've had the "pleasure" of using seem to be vulnerable to this. After 3 failed attempts the account gets permanently locked. You need to go to the bank and personally request that it gets reopened - they don't charge any fees for it, but it IS a hassle. Now, given that this is about finance, one might argue that this is OK. BUT, in nearly ALL the banks I've used bar one, the username is JUST a number. A malicious person could very easily lock accounts left and right for the "lolz". – Shaamaan Apr 06 '17 at 07:51
  • 13
    @Shaamaan A few years ago, I ran into this, but discovered that I'd actually mis-remembered my username, so I had locked someone else out unintentionally. – Joshua Taylor Apr 06 '17 at 17:54
  • 1
    This happens with popular RuneScape streamers. The system locks you out after too many incorrect login attempts. – Mathemats Apr 07 '17 at 00:49
  • 2
    On my very tiny web servers (think, 300-400 users *tops*) I generally do automated but IP-based permanent lockouts. It seems to be sufficient for my casual use cases, and I believe over the past 6 years I've only had to manually unblock maybe 3 or 4 people. – Jason C Apr 07 '17 at 01:40
  • 3
    I've taken down production systems by accidentally trying to log into system accounts with incorrect passwords. Something to keep in mind if you're creating an account lockout policy for system accounts. :) – Tanner Swett Apr 07 '17 at 02:25
  • 10
    @Shaamaan And a certain bank that shall remain unnamed had it even worse, the users were numbered *sequentially* , so anyone could lock out the whole bank with a bit of scripting. – Radovan Garabík Apr 07 '17 at 07:22
  • 1
    the apple id site will lock you up after repeated failed login attempts... and if you have 2-factor authentication you must have the recovery code that was given to you when you first set up the 2FA. If you don't have this, you will loose access to your account. – mamapitufo Apr 07 '17 at 10:39
  • In my own experience, 5-8 years ago this used to be called "freezing" accounts, and many sites in game communities in particular were vulnerable to this. Many used this as an annoyance to rivals/enemies. – esqew Apr 07 '17 at 20:29
  • 2
    @Shaamaan my bank lets me pick (and change) my username. I use a password manager for this purpose. The username belongs to the same entropy class as the password (16 characters long). It is unlikely that I will get locked out. – emory Apr 07 '17 at 21:44
  • @TannerSwett since when did system accounts have passwords or logins? – emory Apr 07 '17 at 21:46
  • 1
    This is known as a Denial of Service attack (DOS), and it's indeed a real threat. – jcaron Apr 07 '17 at 22:09
  • @emory Good for you! Not everyone's as lucky. One of my banks allows the users to pick an alias to help with the login... unfortunately, that doesn't get rid of the numerical username they assign... – Shaamaan Apr 10 '17 at 20:19

6 Answers6

57

Login brute-force protection can be enforced in three ways:

  • Temporary Lockout
  • Permanent Lockout
  • CAPTCHA

In my perspective, CAPTCHA is the most reasonable solution to avoid the risk of bruteforce as well as denial of service due to account lockout. You might have seen a CAPTCHA appearing on the login pages of Facebook and Gmail in case you enter wrong password more than three or four times. That's a decent way of restricting bots from bruteforcing and at the same time avoiding locking users out.

Permanent lockout is not a novel solution, and it adds a lot of operational overhead to customer support team if they have to manually unlock the account for the user. Temporary lockout on the other hand deter bruteforcing, but like the scenario you mentioned, it can lock out a genuine user.

hax
  • 3,851
  • 1
  • 16
  • 34
  • 30
    Don't forget 2FA! – tudor -Reinstate Monica- Apr 05 '17 at 23:54
  • 4
    Also "login patterns". If a person consistently logs in from the same location(s) (IP/browser ID combination), then logins outside that pattern should be treated more cautiously. Additionally, IP changes with the same browser ID should emit a warning to the user by some other communication method. – tudor -Reinstate Monica- Apr 05 '17 at 23:55
  • 19
    It's not only Web sites--nuclear weapons are designed to destroy tiny bits inside if they get wrong firing codes, so that they have to be taken back to the central processing facility to be rebuilt. – chrylis -cautiouslyoptimistic- Apr 06 '17 at 07:41
  • CAPTCHA doesn't really help against bots. I mean, 2 of the 3 ReCAPTCHA methods have already been defeated (one of them even by Google's own services), and the 3rd is only a matter of time. – Nzall Apr 06 '17 at 09:30
  • 11
    [obligatory xkcd](https://xkcd.com/810/) – David Starkey Apr 06 '17 at 14:52
  • @chrylis You have sources of that interesting info? – Xenos Apr 06 '17 at 15:46
  • @tudor Yup. Valid methods. 2FA - Two factor authentication considerably increases the risk of gaining access to resources even if the password can be bruteforced. Though it cannot be strictly categorised as a bruteforce protection mechanism, I believe it is worth mentioning. Nzall You are right. A fool proof solution is far from reality. Even if they all can perfectly distinguish human from computer, nothing can beat CAPTCHA solving farms. – hax Apr 06 '17 at 16:11
  • 2
    @Xenos http://nuclearweaponarchive.org/Usa/Weapons/Pal.html https://en.wikipedia.org/wiki/Permissive_Action_Link#Limited_attempts – chrylis -cautiouslyoptimistic- Apr 06 '17 at 18:03
  • 1
    There's a reason why high-level admins are exempt from lockout despite being the prime targets. – Joshua Apr 07 '17 at 02:42
  • 2
    A lockout longer than a few seconds isn't required at all, just long enough to discourage brute force attempts. Lockouts can be used as denial of service attacks. Ten seconds between attempts, plus logging and an email alert in the case of many attempts ought to do it. – geoO Apr 07 '17 at 03:33
  • There is a fourth option: throttling. This is technically similar to temporary lockout, but with a very small duration for the first failure, then increasingly longer ones for subsequent failures. – biziclop Apr 07 '17 at 14:17
25

Yes, some websites do that in order to prevent bruteforce or password guessing attacks. Instead of banning the user, the website should ban the IP address from accessing the website.

If the attacker is hopping from one IP address to another and doing the brute force attack, then in that case the website can ban the user id and notify the banned user through email or some other way or may be banning the user for a short duration of time will also do the needful.

Peter Mortensen
  • 877
  • 5
  • 10
Skynet
  • 598
  • 5
  • 12
  • 9
    There is a virtually infinite IP space available to any end user in IPv6. – curiousguy Apr 05 '17 at 20:46
  • @curiousguy how easy is it for me to get a new IPv6 address? If the attacker is only DDoSing one account they don't have masses of computers in a botnet. – Tim Apr 05 '17 at 20:53
  • 12
    In IPv6 it would be safe enough to (temporarily) ban an offending /64 without much risk of affecting other users. – Foo Bar Apr 05 '17 at 21:04
  • 2
    Usually, the computer can use 1.8E19 different IPv6 adresses without any effort. – curiousguy Apr 05 '17 at 22:08
  • @curiousguy You say that, but how would one be easily able to obtain new addresses from their ISP? – LegionMammal978 Apr 06 '17 at 02:10
  • 2
    @LegionMammal978 You don't need to obtain those addresses from the ISP because the ISP usually assigns you a whole /64 block. – Yogu Apr 06 '17 at 05:06
  • 7
    yes but as pointed out by @FooBar you don't ban the single IPv6 address but the /64 network. – JFL Apr 06 '17 at 07:49
  • 1
    Businesses, schools, etc. share a /64 or sometimes a /48. One guy can't remember which password he used and you're going to lock out an entire corporation? – Karl Bielefeldt Apr 07 '17 at 12:51
  • 3
    @KarlBielefeldt Lock out the whole corporation from trying to log into one guy's account? Heck yeah, that guy should be the only one on the network trying. – Delioth Apr 07 '17 at 18:25
  • @KarlBielefeldt it's no more than is commonly done today. – hobbs Apr 09 '17 at 06:09
  • @LegionMammal978 "_how would one be easily able to obtain new addresses from their ISP_" This is *not* how IPv6 works. A whole range of adresses, defined by its prefix in binary, is assigned to your router; at least a /64 range (a binary address prefix of 64 bits), that is 1.8E19 distinct adresses, and quite often a /48 range (1E24 adresses) is assigned to the router of a client. The box is responsible for the management of the range. Either the clients use DHCPv6 to request adresses, or they use IPv6 address auto-configuration, in the spirit of Apple's Rendezvous (or Bonjour) protocol/APIPA. – curiousguy Apr 10 '17 at 15:01
  • 1
    @curiousguy Okay, I guess there isn't such a shortage of IPv6 addresses as there is of IPv4 ones – LegionMammal978 Apr 10 '17 at 21:33
5

Other answerers have already offered some valuable means by which a website can prevent abuse of anti-password-guessing measures to lock people out. Here is another one: IP whitelisting.

@Skynet already suggested blacklisting , but with attackers nowadays being able to build botnets well over a million devices in size, that might not be very effective against a resourceful attacker. (Note that an attacker wouldn't necessary have to build such a botnet themselves: many cybercrooks rent out access to their bots.)

So whilst blacklisting could offer a defense against a less powerful attacker, if an attack scales up to a large number of IP addresses, an alternative would be to try to restrict access to IP addresses which have previously been used to successfully log in to the account.

Of course, care still needs to be taken: if an attacker has access to a device that uses a whitelisted IP address, a website should look to ensure this will not allow the attacker to escape brute-force detection. Also, since a user may have a dynamic IP address or for some other reason try to login from a new IP, there needs to be some alternate mechanism by which the user can bypass the login blocking, such as:

  • By entering a CAPTCHA (though be warned: a determined attacker could hire people to solve these at a surprisingly low price);
  • Clicking a link in an e-mail (you'll also want to build in some checks to prevent this from being abused to flood people's inboxes); or
  • Using some kind of two-factor authentication to prove that they are the legitimate owner of the account.
user2428118
  • 2,768
  • 16
  • 23
5

Yes and it has been done before. This can cause a big problem with certain websites. OWASP lists some examples of how it can go wrong on their page on Blocking Brute Force Attacks...

Account lockout is sometimes effective, but only in controlled environments or in cases where the risk is so great that even continuous DoS attacks are preferable to account compromise. In most cases, however, account lockout is insufficient for stopping brute-force attacks. Consider, for example, an auction site on which several bidders are fighting over the same item. If the auction Web site enforced account lockouts, one bidder could simply lock the others' accounts in the last minute of the auction, preventing them from submitting any winning bids. An attacker could use the same technique to block critical financial transactions or e-mail communications.

scorgn
  • 150
  • 2
2

Yes, this is a real threat and is to be considered when you construct your brute-force defenses. These kinds of attacks have been conducted as well, so it's not purely theoretical.

Typically nowadays a system will provide a locked-out user with some means to reset his account, usually through a separate channel (mail, SMS, etc.)

Tom
  • 10,124
  • 18
  • 51
-2

Yes, it's possible. But it can be prevented using CAPTCHA, if the login form has it the only way to achieve this would be manually entering incorrect passwords and is a minor risk. The attacker must be really mad to spend his entire day locking your account

Also you should only indicate the account is locked when the user enters his credentials correctly to prevent account enumeration and never distinguish when the attacker enter the wrong password or if the user doesn't exist

Mr. E
  • 1,954
  • 9
  • 18
  • Depending on the website, it may not require a mad attacker, just a more determined one (White House & gov websites would be very vulnerable to such 24/7 attackers). Basic everyday websites probably don't. – Xenos Apr 05 '17 at 15:55
  • 10
    Huh, if you say it's locked only when you find the right credentials, then it seems very vulnerable: I can keep brute forcing a locked account to know the password, and once found, just wait until it get unlocked. – Xenos Apr 05 '17 at 15:55
  • 4
    You don't even need to reveal that the account is locked - just send a single email to the account holder, and keep using the normal "Incorrect credentials" message for every attempt. – Matthew Apr 05 '17 at 15:56
  • 7
    Mad attackers and backdoored toasters. It's a brave new world, people! – Awn Apr 05 '17 at 15:59
  • 2
    @Xenos: The usual approach for only revealing lock on correct password is to reveal to correct user that the security protocol has been activated and they have to take action. Typically part of the unlocking procedure is to set a new password (effectively re-verify via email, same as a "forgot password" scenario) - this mitigates attacker gaining knowledge through the brute-forcing (if the locked message is shown on the page). In the meantime a far more likely scenario is that attacker gives up or wastes time on the attack by taking useless actions. – Neil Slater Apr 06 '17 at 11:53
  • @NeilSlater If account is locked, you cannot be the "correct user". So you *must not* tell the the one who wants to login that the account is locked. You *may* notify the email linked to the account that it's now locked for some time (but may be used to turn your server into a SPAM one). You *should* not ask this email to change their password (phising opportunities). – Xenos Apr 06 '17 at 15:45
  • @Xenos: Of course you can be the correct user, or at least the original authorised user, just logging in as normal and not part of any concurrent attack - in case we get into terminology differences. Informing that user is a tricky task, email is not a reliable back channel, so a prompt on what would have been a successful login, pointing user at correct process to get the account unlocked, which should require some additional authentication (2fa, email verification etc). If email was reliable, easy and immediate channel, then logins could go via email in the first place – Neil Slater Apr 06 '17 at 16:05
  • Clarification: By "not reliable" I mean "not timely and known to be available to user at point of need". The user you are trying to protect can quite reasonably expect to use the site as normal. If that doesn't work, they need an explanation. They *might* have seen the email informing them of a lockout on their account. They might not. You have to balance reducing confusion of this user versus the risk of allowing a brute force search to complete successfully (which when done remotely over the internet and probably rate-limited, is only a high risk when password is weak). – Neil Slater Apr 06 '17 at 16:10
  • 1
    The attacker has no need to spend his entire day locking the account. If it's just attempting to log in three times every fifteen minutes for a day, there are plenty of people in the world who would do that for the price of a sandwich and a latte in a first-world country. – cjs Apr 06 '17 at 23:58
  • 2
    @NeilSlater To me, it seems you don't get that server cannot tell whether the logged in user is the legitimate one (the one to tell "account locked down") or the attacker who manage to guess the password. A locked account is an account you can no longer *log in* no matter whether you have the right password. I'll end it there (to avoid messing comments). Ask people on tchat to explain you. – Xenos Apr 07 '17 at 08:55