The Exponential Nature of Password Cracking Costs

Application Security Training

The best web app pen-testing course on the market!

Skillset

Let’s assume for a moment that you suffered a security breach for a web application accessed by your customers. Somehow, an intruder was able to evade all the security measures you had in place to breach your website database and was able to obtain all the usernames and password hashes related to your clients.

Under this scenario and putting aside the breach itself, there will be two immediate questions to answer to management. They will be: “How were we protecting user’s passwords?” and “Would the intruder be able to impersonate our clients (obtain their corresponding plain text passwords)?”

These questions are somewhat subjective and to properly answer them, you need to understand the costs of password cracking, and what elements of your password policy affect those costs. In other words, how, from a design perspective, can we make the cracking process more time-intensive thus reducing the ability of an attacker trying to crack a specific set of password hashes in a reasonable amount of time.

Quick point – a reasonable amount of time changes based on the profile of your attacker. A script kiddie might dedicate a few hours to a few days to trying to get access to those passwords. A nation-state attacker may have more resources available and be willing to devote more time to processing the password hashes.

In summary, there are four key components that define the cost of cracking a password:

The hashing algorithm used to protect the password.

The use of salted passwords.

Minimum password length allowed.

The minimum charset required to the users when selecting their passwords. (Which equates to the minimum password complexity required.)

To show how the four components above relate to the initial questions asked by management, I won’t give a definition of these four components. Instead, I’ll present you with a few meaningful examples that illustrate how changes to these components affect the strength of the protection of your users’ passwords.

Example 1 – Cost of cracking a password

Let’s say that the compromised database had only one single password hash corresponding to the site’s administrator. The password was hashed using a hashing algorithm not suitable for password protection (like MD5) and the attacker has access to a very standard computer with an i5 processor and an ATI Radeon 7970 graphics card (which, on Amazon would cost approximately $213 and $443 respectively).

The figure above shows the exponential nature of time needed to crack passwords. As can be seen, in the scenario where the attacker is trying to crack the password using uppercase letters only, using the hardware setup I previously described the attacker won’t be able to cover (at least in two months) all the possible combinations for passwords that are more than 12 characters long.

Example 2 – Enforcing a password complexity policy

For this example let’s use the same preconditions as in example 1. By modifying the charset in use, we’ll obtain the following graphic.

Figure 2 highlights the impact of changing the charset in use. In summary, under the conditions previously defined, an attacker applying brute force will be able to test (in one day):

All the combinations for a ten character password if only uppercase characters are allowed.

All the combinations for a nine character password if uppercase characters & digits are allowed.

All the combinations for an eight character password if uppercase & lowercase characters are allowed.

All the combinations for a seven character password if uppercase, lowercase, digits and symbols are required.

As you can see, the length of the password that can be tested goes down as the complexity increases. So by simply enforcing a reasonable password complexity policy, a developer can drastically reduce the ability of the attacker to decrypt any password of certain length in a timely manner (a meaningful length of time).

Example 3 – Enforcing a minimum password length

For the purpose of this example, we’ll take the original preconditions defined in the first example but we’ll add an additional precondition – the password complexity policy requires users to create passwords having at least one uppercase character, one lowercase character, one digit and one symbol.

Under this scenario, the password length vs. days to crack curve will look like the one presented in figure 3:

As can be seen above, if you enforce a password length of at least 9 characters, including at least one character in each of the aforementioned charset families, the attacker won’t be able to cover the whole space by using his available hardware. The addition of a new character increases the time exponentially.

Example 4 – Selecting the proper hashing algorithm

To work through this example let’s step back and return to the initial scenario. One of our assumptions was having a developer use a weak algorithm (like MD5) to hash the users’ passwords. In this example, we’ll analyze the effect of selecting a strong hashing algorithm to protect stored passwords.

For the purpose of this example, we’ll use the following assumptions:

The compromised database had only one single password hash the one corresponding to site’s administrator.

The attacker has access to a very standard computer with an i5 processor and an ATI Radeon 7970 graphics card.

The password was stored using bcrypt

The difference is dramatic; by using a stronger algorithm to hash the password and forcing the attacker’s hardware to spend more time to process each possible password, we can make it unrealistic for the attacker to reverse a reasonably long password in a given time frame.

Example 5 – The effect of salting passwords

In this final example, let’s assume that the attacker was able to obtain a list of 10 password hashes hashed using MD5.

Now the attacker has a couple of options to get the plain text password, such as using Rainbow Tables or applying brute force. If you decided to salt your passwords you’ll be limiting the options of the attacker (he won’t be able to use Rainbow Tables against the salted passwords) and you’ll be also increasing the time/computational power required to crack the universe of 10 leaked passwords considered in this example (The attacker must run the same brute force attack 10 times, one per password+salt pair included in the list).

Throughout these examples we presented important components to take into consideration while designing your password-based authentication scheme. In any case, you should consider using a combination of these factors as a single measure won’t be really helpful. For example, if you salt your passwords but your password policy allows using passwords like 1234, your efforts to protect your passwords will prove fruitless.

If users are allowed short passwords with no special requirements then their password could still be cracked; but by taking the time to understand what would be possible for an attacker to reverse, we can implement password policies that help elevate the threat and can be easily explained/defended to our users and businesses.

Flavio de Cristofaro is the Vice President of Engineering for Professional Products at CORE Security. He has extensive experience in Information Security & Information Technology and his areas of expertise include IT Risk Management, Penetration Testing, Application Assessment and Application Security. Flavio is a long time password cracking enthusiast who was recently asked to present at AppSecLatam2012 on Lessons learned from Recent Password Leaks.

a) The article seems to assume brute. The bad guys first try large dictionaries + rule based modifications before they revert to brute force. This enables them to crack much longer passwords than the graphs suggest.

b) There seems to be an error in graph for example 4 (md5 vs. bcrypt): The curve for bcrypt and md5 have different shaps above, but they should have exactly the same shape, only shifted to left/right.
This is because f * a^c = a^(c + log_a(f))
f: factor by which md5 is faster than bcrypt
a: character set size (e.g. 26)
c: password length

About InfoSec

InfoSec Institute is the best source for high quality information security training. We have been training Information Security and IT Professionals since 1998 with a diverse lineup of relevant training courses. In the past 16 years, over 50,000 individuals have trusted InfoSec Institute for their professional development needs!

Join our newsletter

File download

First Name

Last Name

Work Phone Number

Work Email Address

Job Title

How will you fund your training?

Why Take This Training?

What is your timeline for training?

InfoSec institute respects your privacy and will never use your personal information for anything other than to notify you of your requested course pricing. We will never sell your information to third parties. You will not be spammed.

Comments

What is Skillset?

Skillset

Practice tests & assessments.

Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready to sit for the test. Along your journey to exam readiness, we will:

1. Determine which required skills your knowledge is sufficient
2. Which required skills you need to work on
3. Recommend specific skills to practice on next
4. Track your progress towards a certification exam