Join Kevin Skoglund for an in-depth discussion in this video Brute-force attacks, part of Programming Foundations: Web Security.
- In the last movie, I mentioned that longer passwords are more secure. Let's explore that topic a bit further, as we discuss Brute Force Attacks. This lock is breakable by a Brute Force Attack. I don't mean using actual force to smash it, or to break the curved shackle, I mean you can find the correct combination to open the lock using Brute Force techniques. First you try the combination 0-0-0, then you try 0-0-1, then 0-0-2, then 0-0-3, and so on, until you get to 9-9-9.
If each wheel has 10 numbers, then it will take you 10 times 10 times 10 attempts to try them all, which is 1,000 possible combinations. It will take you a while, but if each attempt takes one second, this should take no more than 17 minutes to find the right combination. You might get lucky and find it in the first minute, or you might have to wait until minute 15, but no more than 17 minutes to try all the possibilities. Brute Force Attacks on authentication systems, like website login pages, work the same way.
A hacker systematically tries all possible input combinations until they find the correct solution. It's also referred to as an "Exhaustive key search," the idea being that the password is the key that opens the door. So we're exhaustively trying all the keys, searching for the correct answer. We don't have to try all of the keys in sequential order, like we did with our combination lock. In fact, it's often beneficial for hackers to use a dictionary and try using words in the dictionary first. The idea being that users typically use words that are in the dictionary before they use random series of letters and numbers.
A hacker would start with those, hoping to find the solution faster than having to go through the entire set. Now, this is not the same thing as rainbow tables, don't get that confused. Rainbow tables require the hacker to know the encrypted hash and they're trying to reverse engineer it from that hash. This is just simply going to a website, and trying every single possibility, knowing that eventually, you'll stumble on the right answer. And as we saw with our combination lock example, there's a formula for figuring out how long it takes. We take the Key space, that's the number of possibilities for each position in our key, so in our combination lock example, we had the numbers zero through nine on each one of our wheels, therefore we have 10 possibilities.
Therefore we have 10 possibilities, and our Key space is 10. And we raise that to the power of the Key length, that's how many wheels we have in our combination lock. You can imagine that if we added a fourth and fifth wheel to our combination lock, that it would be much more secure than if we just had three of those. Well, this formula tells you exactly how much more secure. So in our case we had 10 raised to the third power, because we had three wheels. And then we multiply that by the time that it takes to make each one of these attempts. And that gives us the total time required to try all possibilities.
Now, that's not the amount of time it takes to break in, because remember we could get very lucky, and stumble on the answer in our first few attempts. It might just take a few seconds, or we might get very unlucky, and it might be one of the last possibilities that we try, in which case it would be closer to the total time required. The Time required is the time required to try all possibilities. And it's in our interest, as someone defending against Brute Force Attacks, to try and make that Time required number as high as possible. So, how can we do that? Well, we have to work with the variables that are in that equation.
First, the Key space we want to be as big a number as possible. And we do that by allowing all characters. We wanna allow uppercase, lowercase, numbers and symbols. The more keys on our keyboard that are available to us, the larger the Key space will be. and the more possibilities that someone would have to try. The second part is to try and make the Key length as big a number as possible. You certainly want to allow long strings to be in passwords, and you can require that a password must be of a certain length in order to guarantee that's it's going to be stronger.
And this makes intuitive sense. If I'm trying all possibilities, and you've got a three-letter password, it's not gonna take me very long to guess it. If it's a much longer password, it'll take significantly longer. Let me illustrate for you the orders of magnitude difference that we're talking about. Let's say that we have two passwords, and the first one's gonna have a combination of lowercase and uppercase letters, numbers and symbols. And in the second one, we're just going to use upper and lowercase letters, and make a very readable sentence. Let's assume that we're using the same Key space for both of these passwords.
That means that even though we chose not to use letters and symbols in the second password, we could have, they were part of the possibilities. So, the first password has 10 characters in it, and it has 48 quintillion possibilities that have to be tried. That's 10 raised to the 18th power. The second password has 17 characters, and has almost three decillion possibilities. That's 10 raised to the 33rd power. It's 60 trillion times stronger than the first one.
Now, obviously the second one is more susceptible to a dictionary attack, which would narrow that down significantly, but we can very easily add in numbers or symbols to that, to improve it even further. I'm not trying to suggest that you shouldn't use numbers and symbols in your password, you should, I'm just trying to make the point that longer passwords are orders of magnitude more secure. So, imagine if we had a password like this: Somewhereovertherainbowskiesareblue. That is trillions and trillions of times more secure than either of the first two passwords.
You get the idea. But there are only so many characters that we can add to the Key space. And there's only so many characters that we want to type in our Key length. I mean, who really wants to enter a 100 character password? So we do what we can on those first two, and then we fight the battle against Brute Force Attacks on our third point, the Time per attempt. Unfortunately, this number is constantly decreasing as computers get faster and hackers have more computing power available to them, as bandwidth increases, so they have the ability to communicate with our server faster, all those things speed up the Time per attempt.
We wanna try and make that take as long as possible. And we're gonna wanna do our best to try and increase that number instead. How do we defend against Brute Force Attacks? Well first, is encourage your users to provide strong passwords. You can require certain things of them, require certain length, require that they use letters, numbers and symbols in their password, or you could provide a mechanism on the webpage that would rate the strength of their password as they type it. There are a number of libraries out there that will do that for you. The second thing that we can do is we can use Slow password hashing algorithms.
You remember when we talked about Blowfish, I had listed that as being one of the benefits of Blowfish, is the fact that it's slow, and that's exactly why. It raises the value of that Time per attempt that's in our equation. But a hashing algorithm that took a half a second longer, would not be a major inconvenience to our users, but would significantly slow down a hacker's attempt to perform a Brute Force Attack. The third thing we can do is Timing and throttling. Your firewall, your web server, or your application, can be configured to slow down the rate at which requests can be received.
You could only allow one password attempt every two seconds. That's not an unreasonable amount of time for a legitimate user to spend typing in and resubmitting a login attempt, after they've had a failed attempt. A good way to throttle attempts is to lock an account after a certain number of failures. And we can pick a high number, like 20, so that most legitimate users don't trigger that. The account doesn't have to stay locked forever, it can only be locked for five or 10 minutes. To a user who has forgotten their password, it's a minor inconvenience, but it's also understandable after 20 failed password attempts.
To a Brute Force Attack, it is a major inconvenience, adding days, weeks, maybe even years to the process. Smart Logging is also a good defense. Do not log the attempted password in plain text, we know that's a bad idea, but you can log the fact that a login was attempted, or log only failed attempts that reach a certain threshold. Logging doesn't have to mean just writing it in a file or a database either. Your software should notify system administrators if suspicious activity is detected. And your final tool against Brute Force Attacks is Blacklisting.
Basically banning an IP address from sending more requests. The problem is that Brute Force Attacks can be distributed across many computers, like botnets. You may have to Blacklist hundreds of IP addresses, but it's the ultimate way to control a hacker's communication with our server. You can't stop Brute Force Attacks, but you can slow them down to the point that they become ineffective.
This course is great for developers who want to secure their client's websites, and for anyone else who wants to learn more about web security.
- Why security matters
- What is a hacker?
- How to write a security policy
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- SQL injection
- Session hijacking and fixation
- Passwords and encryption
- Secure credit card payments