Our passwords are often the only protection our applications have from an attacker. In this video, you’ll learn about password hashing, brute force attacks, and dictionary attacks.
One of the challenges with keeping a system secure is making sure that no one gains access to our authentication credentials. This very often includes a username and, most importantly, a password. This password is usually something secret, and we want to be able to store this information in a way so that we can verify that the user really is typing in the correct password when they log in.
Sometimes you’ll run across an application that stores passwords in the clear. This means this application is storing all of these passwords in a human readable form, usually in one single file that’s somewhere located in this application. This means if an attacker does come across this file, they’ll have access to every username and every password for this application.
If you ever find an application that is storing information in this way, it’s always a best practice to either not use the application or find some other method for storing those password files. This is why it’s always a good best practice to never store passwords as their plain text format, and to always use a format that would be very difficult for an attacker to be able to discover what that password happened to be. And if you are using an application that is storing all of these passwords in a nonhashed, in the clear method, you should consider using a different application or finding a way to modify the current application to store this information securely.
This is where hashing steps in. Hashing is a way to represent data as a fixed length string of text. You’ll often hear this referred to as a message digest, or very often as a fingerprint. For example, us humans could capture our fingerprint and someone else could be able to compare fingerprints to see if one of those happened to match me. What you can’t do is take that fingerprint and somehow reconstruct the individual it was associated with.
This works the same way with cryptography. We can take a hash of a password, and if we want to take another hash later to compare those hashes, we would be able to determine if someone was using the same password.
One interesting characteristic of hashing is that different types of inputs will create very different types of hashes. This allows us to have passwords stored in this hashed form, but have no way to tell how long that password is, how complex the password might be, or what the differences are between one password and another.
Hashing is also not the same thing as encryption. You can’t undo the hash and somehow recreate the password, the stored file, or the video document. This makes hashing a very useful way to store passwords, because there’s no way to look at the hash and have any idea what your password happened to be.
Let’s look at an example of some passwords and what the resulting hash is. The hashing algorithm we’re using in this example is SHA-256. So you could try taking these same passwords, putting them through a SHA-256 hash generator, and you would come up with exactly the same hashes that I have here.
For example, I took the password “123456” and you can see the resulting hash for that password. I also took the password of “1234567,” and you can see that the resulting hash is very different than the one that was just one character off. This is also an important characteristic of hashing that every password, even if it’s changed just a little bit, results in a very different hash.
Here’s also the hashes for “QWERTY,” you can see it listed, out and the password for the word “password.” And you can see that hash. Notice also that each one of these hashes is exactly the same length, even though the passwords we used had a different number of characters.
You can view these hashes in your operating system. If you know where to look. I grabbed one of my Linux boxes and looked at the shadow file, which contains all of the usernames, the user ID numbers, and the hash associated with each user’s password. This is obviously a protected file in the Linux operating system, and not everybody has access to this information, because if you know the hash, there are things you can do to try to determine what the password might be.
I mentioned earlier that we can’t reverse engineer a hash and somehow come up with the original data. This is a one way trip when we’re hashing. So one of the ways that we could take a hash and determine what the password might be will be to try every possible combination of letters, numbers, and characters and compare those combinations to the hash that we have currently stored. We refer to this as a brute force attack. As you can imagine, going through every possible combination of letters, numbers, and special characters might take quite a bit of time. And the longer the password, the longer it takes to cycle through a brute force attack for that particular hash.
Let’s try a brute force attack against a hash to see what that might entail. I have a single hash on the screen, and currently we don’t know what password is associated with that hash. So we’re going to start performing a brute force attack. We know on this system that it can take a minimum of five characters as a password, so we will start with the password “aaaa.” That’s five characters of “a.” And you can see the hash associated with five a’s.
If we compare this with the hash that we’ve stored, we can see that these are very different hashes. So we know that the password associated with our hash is not “aaaaa.” Let’s try the next one in this list, which would be “aaaab,” and we’ll get the hash. We can see those don’t match. So we’ll go to the next, which is “aaaac,” and compare those hashes. And those hashes don’t work, either. So we will continue going through this cycle of changing one character at a time to try to determine if we can find a matching hash.
Eventually, you will find a hash that does match. We finally found one when we reached the “password” combination, and if we see the hash for the word “password,” we can see that it matches the original hash. Therefore, we finally been able to perform a brute force attack and determine that our stored hash is for the word “password.” Depending on the system that you’re using, what you’re searching for, and the process that you’re using to perform this brute force, this could take a number of minutes. It could take hours, or it could take days.
If you were doing this interactively with an online brute force, then you would manually type in a username and manually try a password. You would perform this multiple times, so you would log in with ProfessorMesser.com and try the password “aaaaa.” That didn’t work, so let’s try the next one, the Professor Messer login with a password of “aaaab.” That one did not work, either. And you continue cycling through until you find the right password.
The problem with doing this online, of course, is that most accounts are going to lock out after a small number of failed password attempts, which means even if you do come across the correct password, the system has already locked out that account and it will not tell you that you’ve actually found the right password.
This is why most attackers prefer an offline brute force attack. Once attackers gain access to that hashed password file, they can then download that file and begin performing an offline brute force attack. This is much faster than performing an online brute force. This allows them to calculate the password hash, compare it to what is stored, see if there’s a match, and if there isn’t, they can increment that brute force value and make another comparison. This is obviously going to cycle through thousands and thousands of potential password attempts as we go through the process of trying to brute force just one single hash in that file.
So we can take that shadow file that I gathered from my Linux machine. We can now see all of the hashes associated with these. And now the attacker can sit offline and cycle through all of these in an attempt to determine what these passwords might be. Attackers can also speed up this process by using cloud-based resources, where they can have multiple devices across many different locations, all working together to try to reverse engineer all of these hashes.
Instead of going through every possible combination of letters, numbers, and special characters, why don’t we focus on words that humans tend to use? This will certainly speed up the brute force process, because we’re not checking every possible combination, and we might actually run across some passwords because humans like to use words that we recognize.
We refer to this type of directed attack as a dictionary attack. This is because we’re using words that you might find in any type of dictionary. You might also find custom word lists, as well. If you’re trying to brute force passwords that are associated with a law firm or with a hospital, you might want to use a dictionary attack that specializes in those types of terms.
Some of these dictionary attacks can even enhance the search process by adding in or changing different letters as part of that dictionary attack. So instead of using the word “password” of all characters, it might automatically change the “a” to an ampersand, the “o” to a zero, and so on. This obviously still takes time to go through the brute force process, but we’re obviously using a much smaller group of words to be able to brute force. This speeds up the overall process and might give you a large percentage of passwords.
If you have users that like to use passwords with letters and numbers or jumbled up phrases, then a dictionary attack probably is not going to identify those specific passwords. But if you have people using a password like “ninja,” that’s a very easy one to find in a dictionary attack. The same thing applies to passwords such as “dragon,” “football, “letmein,” or the password of “password.” Although passwords do provide a very useful factor during the authentication process, you can see now we might want to add additional factors along with our username and password.