Password cracking is the process of recovering a secret from scrambled (typically encrypted or hashed) text. This very broad term encompasses many types of password storage and scrambling. As such, not all password-cracking operations are created equal – some passwords, as well as methods of password storage, are easier to crack than others. We will discuss this more throughout this book.

Password cracking can be broken down into various approaches to attempt to recover the secret:

• Dictionary-based
• Combination
• Brute force
• Hybrid
• Partial knowledge, also known as mask attacks

Let’s discuss each of these in turn.

Dictionary-based attacks

Dictionary-based attacks, as you might have guessed based on the name, use a list of words or phrases as password candidates – the potential password we will test to see if it is the correct password. This list is informally referred to as a dictionary, even though it may or may not contain dictionary words. The wordlist may not resemble a dictionary much at all. This term is mostly a holdover to earlier times when many passwords were based on dictionary words, before password complexity requirements (such as adding uppercase letters, numbers, and symbols to a password) were common.

Speaking of complexity requirements, it seems like traditional dictionary words would not be as effective as password candidates during a password-cracking operation due to complexity requirements becoming more commonplace. We’ll address that in the upcoming sections.

Constructing a wordlist for a dictionary attack can be simple or a time-consuming effort. However, in many cases, spending time upfront for a good wordlist tailored to your target may reap dividends at cracking time. The tradeoff here is that your wordlist may not be as reusable for other password-cracking situations. We’ll discuss using open source intelligence (OSINT) to help build a wordlist in Chapter 2, Why Crack When OSINT Will Do?

A good and fairly large wordlist to start with is often the RockYou wordlist. This is named after the breach of the RockYou company in 2009, where over 32 million user credentials were exposed. While available in several places on the internet, a common location to download the RockYou wordlist is https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt. This list contains over 14 million unique password candidates and is also included in many common penetration testing distributions, such as Kali Linux (available at https://www.kali.org/get-kali/#kali-platforms) and Slingshot Linux (available at https://www.sans.org/tools/slingshot/).

Combination attacks

Combination attacks take two wordlists as input and concatenate (append together) one password candidate from each list to create the password candidate for testing purposes. For example, one wordlist might contain the words word1 and word2, while the second wordlist might contain the words word3 and word4.

In this scenario, a combination attack would use a word from both lists to create potential password candidates, such as word1word3, word1word4, word2word3, and word2word4.

Current guidance from the National Institute of Standards and Technology (NIST) recommends password length over complexity for the best resistance to password cracking. This helps encourage our users to create a password that is easy to remember but hard to crack and reflects the current guidance from NIST. This can be performed by stringing several dictionary words together and adding a mnemonic to help the user remember the password. This is only one approach, but this example points out – in conjunction with the current NIST guidance – that combination approaches to password cracking may be more effective as more users follow the guidance to shift to passphrases.

That being said, some standards may slow the adoption of longer, less complex passphrases. For example, the Payment Card Industry Data Security Standard (PCI-DSS) standard, which is required for merchants processing credit card data, requires 12-character passwords, as well as letters and numbers for passwords associated with accounts that have access to cardholder data.

Brute-force attacks

Brute-force attacks do exactly what their name suggests – every position in the password candidate is filled with every possible candidate for that position. For example, if a password can only be eight characters long, a brute-force approach might attempt aaaaaaaa as the password candidate, then attempt aaaaaaab, and so on, until the possibilities for the password are all attempted – exhausted. The problem with this approach is that once a password reaches any reasonable length, the time to perform this style of attack becomes untenable. Additionally, the number of character sets available to use for the password (lowercase, uppercase, numbers, and symbols) will also greatly increase the number of guesses to complete this kind of attack.

The good news for password cracking is that it is possible to crack any password with this approach. However, the amount of time it would take with today’s computing power makes it essentially folly for larger passwords or more complex (more time-consuming for each password guess) algorithms.

Hybrid attacks

Hybrid attacks merge some of the characteristics of combination attacks and brute-force attacks. A hybrid attack uses a wordlist as its base, then modifies the words in the wordlist by adding one or more characters to the word and brute-forcing the character space associated with that. As an example, let’s say I have the following word from my wordlist:

banana

However, I know the password policies of my target require a number in every password. I might try a hybrid attack that takes my word from my wordlist and adds a number after the word. So, now, my password candidates are as follows:

banana1
banana2
banana3
banana4

This allows us to test environments more effectively where users often append (add to the end) or prepend (add to the beginning) some base dictionary word for their password.

Partial knowledge, also known as mask attacks

Mask attacks leverage the idea that we partially understand the format used to construct a password to create a brute-force-like approach that is sped up due to assumptions we make about the password format.

An example will be helpful here. Let’s say that we are testing passwords for a company that requires one uppercase character, one lowercase character, and a number for their passwords. This is a common password complexity requirement in many companies, and many users will meet this requirement by taking a word (dictionary or otherwise), capitalizing the first letter of the word, and appending one or two numbers to the word.

Incidentally, this type of password requirement, along with 90-day password rotation intervals, can lead to the dreaded season-year password, where users will set their password to the name of the current season (Spring, Summer, and so on) and append a two or four-digit year to the password (Spring22/Spring2022, Summer22/Summer2022, and so on).

These complexity requirements may lead us to construct a mask for the password that assumes the user will choose a password that starts with a capital letter, then has five or six characters of lowercase letters, and ends with two or two digits from base10 numbering (0-9). This mask will attempt to brute-force any passwords meeting these lengths and criteria. While this will not retrieve every password in a given list, this approach historically yields high percentages of cracked passwords since this approach is a common one for users to take when constructing passwords.

Important note

We will suggest better methods for password construction and mitigations in Chapter 11.

While it may seem simple, how a password is stored on a system can have a huge effect on its ability to be recovered via password-cracking operations and how long this can take.

You don’t always need to crack!

Most passwords are stored in authentication systems via some process that renders the password difficult to recover. However, it is not unheard of to come across systems that do not protect user credentials appropriately. You may recall that earlier in this chapter, we discussed the RockYou breach. In the case of RockYou, the company stored user passwords in plaintext (no hashing or encryption), which made recovering user passwords trivial. This meant that once user passwords were made publicly available, they were completely exposed – no password cracking or other complex operations were required; they were simply there for the taking.

Let’s talk about the two types of responsible password storage that we typically see: hashing and encryption.

Hashing

The idea behind password hashing is to store the user’s password so that it cannot be retrieved by anyone. There are several advantages to this approach:

• For the company that stores the password, this represents a strong level of due diligence and may provide some protections legally
• Passwords cannot be reverted to plaintext (the original password) from hash values, which means malicious insiders with access to the password storage cannot retrieve the password
• The existence of standard functions to perform this hashing in many application frameworks means it is easy to implement

At its core, hashing takes a string of plaintext (the password) and converts it into a fixed-length string of unreadable data. This value cannot be reverted to plaintext, which is one of the core differences between hashing and encryption. Also, this hashing process will always return the same value for the same input; this is known as being deterministic. Some types of hashing can also add a salt, which adds additional entropy (randomness) to the generation of the hash value. This salt will be different for every password, which can negate the effectiveness of precomputation attacks – a type of attack that generates all possible hashes in advance of a cracking operation (you may have heard of rainbow tables, which are one type of precomputation attack). Hashing algorithms vary in terms of the number of rounds (hash operations) used to create the hash to be stored, the output length, and several other factors. We will discuss various hashing algorithms later when we dive into different types of password retrieval.

In the case of hashing, passwords are validated during the authentication process by taking the password from the user, hashing it, and comparing it against the stored hash. If they match, the password is correct; if they do not, the password that was entered was incorrect. Once again, hashing further protects the plaintext password during this process by ensuring the plaintext password is never handled by the system after hashing.

Encryption

Encryption differs from hashing in that the ciphertext (the product of the encryption algorithm) can be reversed back to the original plaintext (the password). To do this, one or more encryption keys must be generated and used for encrypt and decrypt operations.

Encryption has some liabilities for use as password storage. The most prominent one is that the ciphertext is reversible, which means that a malicious insider or an external party can retrieve the plaintext passwords if they can obtain the ciphertext and the encryption key(s). Additionally, because it is used in encrypt and decrypt operations, the key(s) must be retrievable, which further increases the potential for mishandling and/or disclosure of the keys.

Easy check for encryption as password hashing (or worse)

Have you ever forgotten a password and used a Forgot Password link or workflow in an application? Odds are, you probably have. If you have ever used the Forgot Password functionality and had your password sent to you via email or some other cleartext method (rather than being prompted to set a new password), this means that your password is stored on that system in an encrypted format. If password hashing was in use, they would not be able to retrieve your plaintext password.Well, there’s one other possibility – the system is storing your password in cleartext, similar to what RockYou did. We have seen how that is a very bad idea, but unfortunately, it is sometimes done.

In the case of authentication with encrypted passwords, the ciphertext can be compared (similar to authentication with hashing in use), or the password can be decrypted and compared to validate the password provided by the user.

While encryption has been noted here for completeness, it is not at all optimal to use encryption for password storage and is not recommended in the NIST 800-53 standards.

There are several reasons for this, but it boils down to one thing: how long it takes for a system to guess the password correctly. If we can create passwords that increase the amount of time for this to happen, we are creating a password that is more difficult to crack. If we create passwords that decrease the amount of time needed for password guessing to be successful, we are creating a password that is easier to crack.

So, what are some of the factors that make a password easier (or more difficult) to crack? Some of the most important are as follows:

• Password length
• Password complexity
• Time to hash/encrypt the password

Let’s talk about each of these in turn.

Password length

Password length is often thought about by the end user in terms of the bare minimum. In other words, if a system requires an eight-character password at a minimum, many users will select an eight-character password.

At the time of writing, NIST maintains its password recommendations at an eight-character minimum. This is noted in NIST Special Publication (SP) 800-53B and is updated from time to time. However, NIST also notes that systems should accept a password from a user of at least 64 characters.

Let’s think about that eight-character password for a moment. How many guesses would I need to make to determine someone’s eight-character password? The answer, as with so many things in information security, is that it depends. Let’s start with a simple character set that consists of the 26 (lowercase) letters of the English alphabet. The number of guesses required to successfully determine this password is represented by x to the power of y or xy, where x is the possible characters in each position of the password, and y is the number of total characters in the password. For our 26-character lowercase password, which is 8 characters in length, it will take 268 guesses, or 208,827,064,576 guesses. Note that this is the maximum number of guesses – this represents someone guessing every possible password and only being successful on the last guess. This is a lot of possible guesses! But does this mean this password is secure? Again, it depends. How quickly can we try a guess and validate if it is or is not the password? Even milliseconds less or more per guess can have a large impact on the overall time to work through all the possibilities.

What if we choose a password length that is longer than the minimum recommendation from NIST? What about nine characters with the same lowercase English alphabet? That’s 269 or 5,429,503,678,976. This is, as you might expect, 26 times more guesses than what we needed to make for an eight-character password.

By the time we get to a 12-character password, with our same 26-character set, we are looking at 2612, or 95,428,956,661,682,176 (also known as roughly 95 quadrillion guesses). This is 456,976 times the number of guesses required for an eight-character password!

Visualizing this in a graph (see Figure 1.1), we can see an exponential growth of guesses required for every character increase of the password length:

Figure 1.1 – Number of guesses for 8 to 14-character passwords (26 possible characters)

For those building secure systems, this is good, and this means every character counts when it comes to password length. The longer a password is, the longer it will take to crack, and the more secure (resistant to cracking) it is.

Password complexity

The idea behind password complexity, like password length, is to make a password more resistant to cracking. However, complexity takes a different approach – for every character in the password, we increase the possible characters that can be used to fill that spot. Let’s see how this works in practice by revisiting our math in the previous section.

If we add uppercase English alphabet characters to our lowercase English alphabet characters, we get 52 possible characters. So, now, our 8-character password will require 528 guesses, or 53,459,728,531,456. Here, adding an additional 26 characters significantly increases the number of guesses. Furthermore, because this is an exponential operation, the increase in the number of guesses per character can be visualized in the same way as the 26-character password as length increases (see Figure 1.2):

Figure 1.2 – Number of guesses for eight to 12-character passwords (52 possible characters)

As shown in Figure 1.1, increasing password length increases the total guesses required to identify a password. Likewise, in Figure 1.2, we can see that increasing the complexity of the password increases the guesses required, and increasing both length and complexity raises the number of guesses required even faster! So, which is better? Or should we use both? For this answer, we need to look at the math, and then follow it up with psychology.

An eight-character password with uppercase and lowercase letters requires 53,459,728,531,456 (53 trillion) maximum guesses. A 10-character lowercase-only password will require almost three times as many guesses – 141 trillion. Now, let’s move on to the psychology. Which will be easier for a human to remember – an all-lowercase series of characters, or a series of uppercase and lowercase characters? One of two things will likely happen:

• The user will create a password that’s easy for them to remember by capitalizing the first letter of the password and leaving the rest lowercase. This is trivial to address in cracking and subverts the point of adding the additional character set. If the first letter of the password is capitalized, there are 26 possible choices, meaning the same number of choices when we use lowercase characters. If the user then leaves the rest of the password lowercase, there are only 26 possible choices per character there as well. In this scenario, with an eight-character password, we have 268 possibilities instead of 528 possibilities – the same number as if the password had just been lowercase to begin with!
• The second possibility is that the user creates a hard-to-remember password and writes it down either on paper or in a password manager. While the use of a password manager is generally desired behavior, writing a password down where it might be discovered is not.

So, where does this leave us? The human mind will find an all-lowercase password to be easier to remember than a series of uppercase and lowercase letters, a series of upper and lowercase letters and numbers, or a series of upper and lowercase letters, numbers, and symbols. We can increase the length of all lowercase passwords and still create a password that is resistant to cracking. This is the current NIST recommendation – the current revision of SP 800-53B suggests that creating a password should not require password composition rules to be used (section 5.1.1.2).

Time to hash/encrypt the password

The third major factor in creating passwords that are resistant to cracking is not in the selection of the password itself, but rather the computational operations to create the hash and how long they take. Think about the number of guesses required for the various types of passwords we discussed earlier. Each of those guesses takes a non-zero amount of time to perform. We must calculate the hash for that password candidate, and then compare it against the known hash to see if they match (meaning our password candidate is our password).

If this operation takes a full second, instead of half a second, the overall time for the cracking process is doubled. In reality, guesses will occur much faster than that but for the sake of illustration, you can see how that makes a huge difference against the number of guesses we are dealing with in these scenarios.

Hashing algorithms are designed to be fast. Hashing is a common computational operation for comparisons, and we want them to be fast. However, we want password hashing specifically to be slow – we want it to be as slow as we can reasonably get away with. The slower the password hashing operation, the more resistant the implementation will be to cracking by making each attempt more computationally expensive. Password hashing algorithms such as PBKDF2 use common hashing algorithms such as SHA-512 but run many rounds of that hashing algorithm to increase the time to create the password hash.

While increased time per hash will result in a slower cracking operation, the cracker can attempt to offset this by increasing the number of hashes they perform per second, either by increasing the computational power used by the cracking process or distributing the load of the cracking operation across multiple computational engines. In Part 2, Password Cracking Types and Approaches, we will look at the overall speed of various cracking operations based on the types of hashes we are cracking.

Regardless of the approach, the objective of this book is to help you with the tools and techniques you need to recover passwords, whether you are in a penetration test/red team operation, you are recovering a password of a user backup for someone who has unfortunately passed away, or anything in between.

The important caveat here is that this book focuses on ethical password cracking. The purpose of this book is not to help you circumvent laws or perform illegal activities. Rather, its purpose is to give you what you need to be successful in pointing out flaws in penetration testing engagements, or other approved means to enable your business.

Please ensure you consult with your legal counsel and/or company counsel before performing these techniques against passwords in your company.

In this chapter, we introduced you to the concept of password cracking, the various types of cracking attacks, how passwords are stored and used, and some of the reasoning behind what makes a stronger password. With this, you have laid the groundwork to get started with various types of password cracking.

However, wouldn’t it be easier if we never had to crack a password at all? In some cases, we can, because of readily available information such as previous data breaches and poor password practices such as password reuse. In the next chapter, we will examine how to use OSINT to find information from previous breaches or to build custom wordlists for specific targets.