They will; just not how you think.
What you’ve described is called a brute force attack, and you’re quite right; it’s a rare system that allows such an attack to proceed past the first few failures.
However, hackers have other options up their sleeves. We’ll look at simple and targeted brute force attacks and consider how our choice of passwords can keep us safest.
Become a Patron of Ask Leo! and go ad-free!
Brute force attacks
Brute force attacks on login screens are rare because they’re slow, rarely successful, and easily blocked. More common are offline brute force attacks on user account databases stolen via breaching online systems. There, hackers can try all possible passwords up to a certain length, or more commonly, try all previously discovered and known popular passwords.
Simple brute force
The attack you’re thinking of involves the hacker trying to log in using your user ID with every possible password, one after the other, in turn. You might think of it as manual — a hacker sitting at a keyboard, trying over and over again — but there are automated approaches as well.
Most systems notice that the same person has tried to log in unsuccessfully too many times and lock the account for a few minutes or for an extended period.
But to be honest, even when systems are operating at full speed, the login process is usually slow enough on its own to make this type of brute force attempt impractical. If you had to try logging over and over again, it would take forever, no matter how fast you were.
Not surprisingly, that’s not what hackers do. If they’re going to attack by trying to log in, they’ll stack the deck instead.
Targeted brute force
You’ve probably seen the reports that come out every year revealing the top 100 most popular passwords. We use it as an example of how unsafe easy passwords are.
Hackers use those lists, too. In fact, hackers use much longer lists of passwords.
Hackers “stack the deck” by taking the top 1,000 or 10,000 or 100,000 passwords and trying them in order of popularity. Given how many people use bad passwords, it’s worth the hackers’ time to try the most common — manually or with automation — even if there are periodic delays.
Just the top 1,000 passwords tried against a large enough number of accounts will get them access to a depressingly large number of them.
But there’s a different way for hackers to try every possible password.
How passwords are stored
Before we proceed, we need to review how passwords are stored.
I’ve talked and written before about how most services store your password. They create what’s called a hash of the password.
The (very bad) password password has a hash of 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8. That’s a number calculated by a complex algorithm (sha1, in this case), represented in hexadecimal. You’ll normally never see a hash.
Think of a hash as a one-way encryption that can’t be reversed. You can create a hash from a password, but you can’t get the password from the hash. On top of that, it’s statistically impossible1 for two passwords to generate the same hash.
When you set your password, the service creates the hash associated with it and stores the hash, not your password.
When you log in, the service again calculates the hash of whatever you typed in as your password. It compares this hash with the hash it created when you set your password. If those two hashes match, then you must have typed in the same password this time as you did when you created the password.
Databases of passwords
Now that we’ve seen how systems store passwords, we can look at how hackers leverage the system to their advantage.
We’ve all heard about data breaches at large companies. A hacker gets in and gains access to information they’re not supposed to.
One goal of most breaches is to get a copy of the user-account database. That’s the list of all the user IDs and password hashes. With that database in hand, the hackers can later, on their own computers and at extremely high speed, try every possible password.
For each possible password, they use a program that calculates the hash2 and looks to see if it’s anywhere in the stolen database. If it is, they now know the password for the user account having that hash; it’s the password they just used to calculate the hash they found.
This is where password length and complexity come into play.
It’s currently possible to do this in a short amount of time with every possible eight-character password. That’s why industry experts now say 12 characters is the bare minimum length of a password. The time required to try them all increases exponentially each time you add even a single character to the length. It’s just not practical for hackers to try all possible 12-character passwords today. Even with the best equipment, it would take years.
But, as it turns out, length isn’t enough either.
Previously used passwords
As more and more breaches happen, more and more actual passwords are discovered. This can be because the service wasn’t storing passwords properly, the password was encountered in the “try everything” approach I discussed above, or the password was compromised some other way.
Hackers collect passwords they’ve discovered.
What this means is that when they have a database captured in a breach, rather than trying all possible passwords, first they try all previously discovered passwords. It’s more effective, and the length, or even the complexity, of the passwords doesn’t come into play. All that matters is that the password was once somewhere, somehow compromised.
Why is it more effective? Because people reuse passwords.
This is why you shouldn’t reuse passwords. If your password — no matter how wonderfully strong — is discovered even once, hackers just add it to their list of passwords to try everywhere. If you’ve reused the password, that additional account could become compromised. Use each password once and only once.
Do this
Yes, hackers can try all possible passwords; they just don’t do it by trying to log in with each one. Using stolen user-account databases and databases of popular and previously discovered passwords, they work offline at high speed to figure out your password’s hash. When they later arrive at the log-in screen, they know exactly what to type in, and only need one try to get into your account successfully.
The lesson here, of course, is to choose long, complex passwords. The longer the better, in fact. I now use passwords with 20 random characters whenever I can. I let my password vault create and remember them for me.
Yes, it’s possible that even those can be compromised by malware such as keyloggers, which is why I also advise you to:
- Never reuse passwords.
- Add two-factor authentication to accounts that support it.
With two-factor authentication enabled, even discovering your password isn’t enough to get in.
Want more confidence keeping your accounts safe? Subscribe to Confident Computing! Solutions, answers, and tips in your inbox every week.
Podcast audio
Related Video
Footnotes & References
1: I say “statistically” because it’s extremely improbable for two different passwords to create the same hash. There remains the tiniest sliver of a possibility, but it’s so tiny as to be effectively nonexistent.
2: Or use precomputed tables of all possible passwords and hash values. These tables are huge but faster to use. They’re referred to as rainbow tables.
Leo,
This is unrelated to the above excellent article, I also use 1Password and find it indispensable.
But, here is my plea for help:
Couple years ago I updated Microsoft Office and somehow the update caused two mailboxes of the same name to be created. Email randomly comes to both, never the same email to both however, without obvious reason. How do I safely eliminate one of these mailboxes please?
I’m curious. If a password, such as “Fido”, creates the hash “5baa61e4c9b93f”, and the password is changed to “Fidodog”, does the first part of the original hash for “Fido” change appreciably?
Sometimes when I log into a website, the service will see I’m using a different computer and ask for additional verification, like my first car (the correct answer for me would be “spaghetti”). Kudos to those companies. If I was using a different computer (or perhaps a hacker on their computer), I only wish they would ask for additional verification whether the password was right or wrong. If the password or additional information was incorrect, respond with “either the password was incorrect or the additional information was incorrect”. A hacker would have two problems to solve.
If a password changes in even the smallest way (Fido -> fido, which is a one-bit change), the new hash will be COMPLETELY different. That’s one of the characteristics of a good hash algorithm: a small change on input results in a massive change on output.
Example:
sha1 hash of “Fido”: c6eab3324f4657a4c4c751fa472155eef159a4c8
sha1 hash of “fido”: cc22a138b5b04eb06600eabb1a1cd19ccf50e930
Adding even one letter or even one bit to a password would not only change the first par to the hash, it would change the hash completely indistinguishable from the original. The hash is a result of a complex cryptographic mathematical calculation.
Here is an example of a hash of fido using the SHA3-224 hash
8e44d0792d554f19d0bce11db99499e3260e97fcf83ec6b659549360
and here is a hash of fido1
6fd945c44c2f98a28d6b1a5d181b52aedcaa6c1ff61fc46d468ab484
If you want to play with it here’s a website that calculates hashes,
https://www.browserling.com/tools/all-hashes
I must be missing something. In order for a hacker to be able to make use of an exposed hash database, he must be able to apply the same hashing algorithm used by the legitimate owner of that database. It would seem that the number of potential hashing algorithms would explode the required trials geometrically. Do hackers also use a database of potential hash algorithms that are well established?
Basically, yes. It’s quite possible for security, when done properly, to make attacking the database of hashes impractical as well. (A little salt can often ruin the entire effort.) Unfortunately two things: 1) “done properly” isn’t always, and 2) often the same breach that allowed the hacker to exfiltrate the database may also have given them access to the code implementing the hashing algorithm.
Even though you recommend never using the same password for different sites I do it often for sites that I don’t care much if someone logs onto my account. For example, I use the same eight-character upper & lower case letters plus special characters password for Consumer Reports as I do for CVS Pharmacy and several other sites. My reasoning is that I can’t think of anything a hacker could do on these sites that would be extremely harmful to me. First question: Am I being naive about this and exposing myself to harm?
And I let my Firefox browser memorize the password for those sites but not for others that I consider more sensitive, such as my bank. Second question: Am I being too paranoid about the safety or lack thereof for browser-memorized passwords?
Naïve, no, but you may be overlooking a few things. I have an article coming out in a couple of weeks that addresses this very topic.
I tend to avoid letting the browser remember passwords: Is It Safe to Let Your Browser Remember Passwords?
I really appreciated your video/article. I am sorry for likely asking a pretty ignorant question (actually 2 questions).
I am getting ready to launch an online community using Buddyboss, so it is WordPress based. I am using Wordfence currently and have questions about the Bruteforce attacks
(1) I don’t understand how hackers can get in when they need to know both: the Username/email AND the password? Related to that, I keep wondering how they are trying passwords not having a correct username? What am I missing?
(2) I keep seeing the same (non-registered) Username trying to log in — using the same IP address a few times; then others the next day. I only noticed that it is the SAME username doing it over weeks and now months I think. Does that seem like a coordinated long-term attack/attempt to get in? It really confuses me. I tried to find a way to do some custom blocking in Wordfence of that user name but have not found a way. Also, they are using the extension of the platform I am using as part of that username, which is buddyboss. They username they are using is {URL removed}
I’d love any ideas you might have!
1) You’re not missing much. The brute force attacks involve both different usernames and passwords. The only tweak is that there are some common usernames (think “admin”, though that’s no longer a thing on WordPress). So they can narrow the pool of usernames to those common ones. Also it’s sometimes possible to infer common usernames from actual names present on the site (as in comments). If Leo Notenboom comments then there may well be a Leo, LeoN, or LNotenboom username, so all three could get put into the pool to be tested against. Finally, email addresses as usernames are often just pulled from breaches of known good email addresses regardless of whether they’re known to be used on website logins.
2) Is a great example of what is probably a default username for some plugin, hosting service, or other scenario.
The key is that the attacks are slow, persistent, and very patient. They don’t work often, but they do work occassionally.