Brute force hacking is a crude form of hacking by guessing passwords over and over again until you guess right. As you may guess, it can be rather time consuming. But there are more than 40 gigabytes’ worth of stolen usernames and passwords in circulation that we know about, so obviously, it works.
In computing in general, brute force refers to getting something done inelegantly, relying on persistence and the computer’s ability to repeat things over and over quickly until it’s successful. Here’s how brute force hacking works, and some ways to prevent it.
Brute force hacking normal logins
Many years ago, I was setting up a log collection system. One of the things I had to do was collect logs from a mainframe. The only way I could get it to work was to get the mainframe to FTPS (not SFTP, and not FTP) into an intermediate system, then have the log collector FTPS into the intermediate system and grab the logs.
One day I came into work and found the log collection had failed, and the accounts were locked on my FTPS server. A system called Qualys had found my server and tried to bruteforce its way in. That was cool.
What Qualys did was try several common usernames and several common passwords to see if any of them worked. And Qualys didn’t guess any of them, because my passwords were long and obnoxious, but it did lock the accounts. Since this tends to break important stuff, most people disable the password brute forcing option in their Qualys scans, but for whatever reason, whoever launched this particular scan didn’t.
Defeating brute force hacking normal logins
There are several ways to defeat brute force hacking through normal login processes. The first is to limit the number of attempts until the account locks. Most people set it at three or four.
Not using standard usernames is another common trick. The administrator account on your Windows machines shouldn’t be named Administrator. Name it something that blends in, like, oh, bmiller. Rename the guest account too, and plant a few other dummy accounts so it’s not clear which account is your renamed administrator account. Then create an account with no rights, disable it, and name it Administrator.
Renaming the root account on Unix and Linux systems isn’t considered a good practice, as many Unix utilities assume your superuser account is root and only root.
The third trick is introducing delays between attempts. Making a human wait five or six seconds between login attempts isn’t all that big of a deal. You slow down normal logins a bit, especially on Mondays, but it’s a minor inconvenience. Brute force hacking relies on working as quickly as possible though, so those delays of a few seconds really throw a wrench in things.
The fourth and best trick is requiring complex passwords. They’re going to guess passwords like password1 and 12345678 and qwertyui or even 1q2w3e4r first. If you require passwords to contain numbers and mixed-case letters, the accounts will lock before the attacker can get around to trying those.
There’s a fifth trick too. Set up event monitoring. When you see someone trying to log in using the Administrator account, log it and alert on it. It could be an innocent mistake. If it’s something worse, someone’s looking into it.
Brute force hacking a stolen database
Brute force hacking through a normal login process is horribly inefficient, so it’s more common for it to happen against a stolen database file. Good systems don’t store passwords in plaintext. They store a hashed version of a password. A hash is similar to encryption, but it’s not encryption. It’s not reversible. When a user logs in, the system hashes the password the user enters, looks for a match, and lets the user in if it matches. Or it rejects the login if it doesn’t match. There’s no such thing as close enough, for reasons we’re about to see.
MD5 is an obsolete but still-common method for hashing. Here’s what the word password looks like after you hash it with MD5:
Here’s what passw0rd looks like after you hash it with MD5:
It’s completely different, even though I changed a single character. As far as the computer is concerned, they’re two completely different words. And there’s no way to derive one from the other.
The slow way to brute force that database is to MD5 passwords and compare them one at a time. The faster way to do it is to MD5 millions of possible passwords in advance, then cycle through the database looking for matches on each of them, and output any matches in plaintext to a second file.
Human beings only use a few million of the possible passwords we could use, at best, so it doesn’t take all that long to cycle through a stolen database and find matches. SSDs and super-fast CPUs make the task trivial today.
Matching known hashes against unknown hashes is called a dictionary attack.
Defeating dictionary attacks
There are several ways to defeat dictionary attacks too, besides the obvious one of keeping someone from stealing your database. Even if your security keeps 100% of outsiders out, you can’t stop a disgruntled insider with a privileged account from stealing the database.
Requiring complex passwords helps stop dictionary attacks too, or it at least slows them way down. It takes much longer to cycle through every possible 12-character password than it does to cycle through every possible 8-character password. We know they’ll cheat and just cycle through likely 12-character passwords, but there are more of those than likely 8-character passwords.
Using a more complex hashing algorithm also helps. MD5 is too fast, and it’s also prone to collisions. A collision is when two words get the same hash. If the words sam and ed get the same hash, and I set my password to sam and you guess ed, the system lets you in because it can’t see the difference. Using a more intense hashing algorithm doesn’t slow logins down all that much, but it slows down attackers trying to hash millions of passwords, and it theoretically eliminates collisions.
A third preventative measure is salting the data. Salting refers to secretly changing the data before hashing it. If you tack the number 1 on the end of every password before you hash it, that changes the hash dramatically. If I don’t know what you do to your passwords before you hash them, I have to figure it out. So now I don’t have to do one brute force attack. I have to do many.
Attacking a salted database
About the only way to attack a salted database is to take a common password like password123, salt it, then look for matches. If you don’t find a match, salt it with something else, then repeat.
As you can see, the other mitigating effects are cumulative. An insider could try to crack his or her own password to find the salt. But an outsider doesn’t have that advantage. If everyone uses long, complex passwords, so there’s nothing like password123 in the mix, there’s no way to guess the salt.
An attacker can hash salted variations of password123 in advance, but they can’t do that for all passwords. It’s not practical to store that many hashes. Once they get the salt, then they have to salt and hash their dictionary, which will take time. The more complex the hashing algorithm, the more time it takes.
If you have a good salt and all your passwords are long and complex and you use a good, modern hashing algorithm, brute force hacking a stolen dictionary is infeasible for an outsider.
Brute force hacking your own users’ passwords
In the mid 1990s, I had an account on my college’s Unix system. One day, about three weeks after changing my password, I got e-mail saying to change my password again. They didn’t go into detail about their methodology, but they’d done a dictionary attack against the system’s password database and successfully guessed my password.
It’s best to have a policy regarding password length and complexity and reject passwords that don’t pass right away. But brute force hacking your own database is a good second line of defense.
Defeating brute force hacking
As you can see, a combination of good password policy and good development policies can make brute force hacking much less feasible. And good practices tend to accumulate, so in the case of interactive logins, you can catch someone in the act and stop them before they get any further. If you’re noticing a pattern here, I’m not saying to work with a safety net. I’m saying to have several safety nets.
A better option is using some kind of multifactor authentication. An example of this is requiring you to have a username and password, but then sending you a text message with a numeric code and making you respond with the code. Then you can let up a bit on the password complexity requirements, since the chances of you guessing my password, stealing my phone, and being able to unlock my phone are acceptably low.