Why are brute-force password-cracking attacks not automatically detected and thwarted?

Question

Why doesn't software automatically detect password-cracking attacks, and thwart them?

---

Long version:

Suppose that someone tries a brute-force password-cracking attack on some program XYZ that requires password authentication.

My understanding is that such an attack would consist of iterating over the set of "all possible passwords", supplying each in turn to XYZ, until one of them works. For this strategy to have any probability of success, the attacker would have to be able to supply to XYZ very many candidate passwords per second. Therefore, it would be trivial to program XYZ to detect this pattern (that is, distinguish it from the case where a legitimate user mistypes the correct password a few times), and automatically escalate the authentication requirement for the next, say, 10 minutes.

The idea is that the owner of XYZ would be allowed to set two "passwords": a "level 1 password" (AKA "the password") that is relatively easy to remember and easy to type, but also relatively easy to crack by brute force, and a "level 2 password" (AKA "the passphrase") that could be extremely long, impossible to crack by brute force, but also very inconvenient for (legitimate) daily use.

Someone who knew the convenient-but-weak password would hardly ever need to use the uncrackable-but-inconvenient passphrase.

I'm sure there's some huge flaw in this scheme, otherwise passwords would not the headache to legitimate users that it is. What is the explanation?

Answer 1

Reasonably often, they do. Any reasonable system will lock you out if you make too many online attacks (or legitimate incorrect attempts) to access the account.

The problem comes with offline attacks. The server (or whatever you are authenticating too) has to have something to compare the password to. This is typically either an encrypted value that can be decrypted with the password or a hash. If this value is compromised, such as when an attacker gains access to the database of users, they can then try to run the hash or decryption on their own computer and bypass all the counts of how many times things have been tried. They can also try guessing orders of magnitude faster since they are working locally and don't have to wait for a network.

With an offline attack, it is possible to try thousands if not millions of attacks a second and it suddenly becomes trivial to attack simple passwords within minutes, if not seconds. There is no way to prevent the attack since we have no control over the system being used to check the password. This is why it is important to change your password after a DB compromise is discovered.

Answer 2

For "online attacks", they do, to various extents and with varying success. Usually, it's merely an annoyance to the legitimate user and not a big deterrent for criminals.
For offline attacks it is impossible. If someone has your password database, you can't prevent them from doing something with it (though you can delay them somewhat).

Cell phones operate in the exact manner that you describe. After entering your PIN incorectly beyond some threshold (e.g. 3 attempts), you need the PUK to unblock the device. If that ever happens to me, I'll be greatly pissed, since I threw away the piece of paper where that 10-digit number is noted.

My AVM router will lock you out for 5 seconds, doubling the amount of time with every failed login. Thus, after 10 failed attempts you have a 42 minute wait before you can retry.

Such a scheme is, however, only moderately intelligent. While it is unlikely that you will have a typing error 10 times in a row, it is perfectly possible that you can't remember which of the 10 passwords (passwords that you use rarely in a variety of places, or among passwords that you have changed over time) is the correct one. Also, it allows for a denial of service attack with comparatively little work.
Of course, the attacker, too, has to wait between login attempts, but he only waits 21 minutes where you will have to wait 42 minutes (or 6 hours while you wait 12). Also, if someone is just being malicious, waiting doesn't hurt, you can always set an alarm clock to 6 hours, and do another false login in the evening. For the legitimate user, it will be a complete day of waiting, if this works out (and more importantly, waiting does hurt if you actually need to do something).
Other systems that I've seen with some websites are even less intelligent. In one case, a few years back, I've been forced to change my password to unlock my account because someone did a couple of false logins. Which is, of course, total nonsense since the password had demonstrably not been compromised (as these login attempts were unsuccessful). That "security" measure was only a very major annoyance for the customer, with no benefit.

In the implementors' defence, it is not at all easy (if possible) to come up with something that works much better.

Answer 3

There is one other scenario that would be difficult to detect.

First lets look at scenarios that are easy to defend against;

Easy: Defence against brute force attack on a single user.

Brute force attacks are also easy to defend against, if a single user is the target of the attack. We can just lock that user's account. This may annoy the user, but it allows us to prevent the system from being compromised.

• login to UserJoe
• login to UserJoe
• login to UserJoe
• login to UserJoe
• login to UserJoe
• Lock UserJoe's account

Easy: Defence against brute force attack from single IP address

Brute force attacks that are easy to detect and defend against, if all of the requests come from the same IP address.

We can just bar that IP address from making any more requests.

• SomeIPAddress1 attempting to login
• SomeIPAddress1 attempting to login
• SomeIPAddress1 attempting to login
• SomeIPAddress1 attempting to login
• Prevent SomeIPAddress1 from attempting future logins

Impossible (?): Defence against a botnet brute-forcing new user on every attempt.

Suppose that someone using a botnet is trying to brute force your system. They have will have different IP addresses so you can't filter logins by IP address.

Next suppose that they try to login to a different user every attempt.

So the requests could look like this:

• SomeIPAddress1 attempting to login to UserJoe
• SomeIPAddress2 attempting to login to UserAnne
• SomeIPAddress3 attempting to login to UserMarc
• SomeIPAddress4 attempting to login to UserHanah
• ...

I can't think of any way to differentiate legitimate logins from fake logins.

Answer 4

It's always going to be a balancing act of how much time to make someone wait after an incorrect login attempt. It's not unreasonable to keep increasing the wait time after each attempt (and eventually lock out further attempts until some sort of reset), but this needs to be tied to the IP address the attempt is coming in on, so that the legitimate user doesn't get locked out, too (victimized because someone is trying to break into their account). However, a distributed attack (from many IP addresses) can load down the system to the point that it just becomes a plain DDoS attack.

If someone is determined to try a whole bunch of passwords (not necessarily every possible one, just the most common/likely ones) and has a herd of zombified machines to do it, either they'll eventually succeed, or bring the system to its knees. Don't forget that enforcing a wait time (turning away login requests) or denying an IP address also uses up resources. And if you have so many passwords that you can't remember which one to use, you've got a problem with your methodology if you have to go through all of them!

A "security question" challenge (basically, an alternate password) after so many failed attempts is possible, as is mailing a one-use password (reset) to a registered email address (whether automatically or "forgot password" request), as is a lockout on this IP address for a given time or until an administrator is asked to unlock it. I've seen all these methods used.

If the attacker has inside information, namely, the hashed or encrypted password file, they can do most of their work offline and just log in once (after they figure out the password to use). Passwords should always be stored as hashes (one-way encryptions), and never in plain text or even in a reversible encrypted form. Hashes are difficult (but not impossible) to recover the plain text password from, especially if they're salted (so that the hash is not the same for two different users who happened to choose "secret" for their password).

Answer 5

Because customer do not pay for security.

You need to create a database table. Collect IP addresses from failed logins. Cleanup this table regularly. Create another table with blocked IP addresses and keep it cleaned up too. You see it takes some effort, and customers don't like to pay extra just for security.

As a developer you should use frameworks which will take care of those problems. Also you might want to have a look at fail2ban.