# Security Science?

/As a Security Scientist, I’m often asked “What is Security Science?” and “ What does Security Science mean?” This post is an attempt to explain its role and to showcase its function.

As a tenant of DevSecOps, Security Science is tasked with bringing the rigors of scientific inquiry to the F.U.D. (Fear, Uncertainty, and Doubt) of typical information security practices.

Now, calling typical information security practices F.U.D. is an insult that most practitioners would take serious offense to. But, let’s look at a simple but enlightening example.

**What is your password policy? **

It’s a very simple question. You likely have a well-documented policy that states (as an example) that…

- Passwords must be at least 8 characters long.
- Each password must contain all of the following:
- Upper case letters
- Lower case letters
- Numbers
- Special Characters

- Passwords must be changed every 90 days
- Passwords not use any of the following as part of a password:
- Words found in standard dictionaries
- Your own name or the names of family members, pets, or favorite hobbies
- Predictable variations such as “12345Jan”, “12345Feb”, etc.
- Any other fact about you that is well known or easily discoverable

That’s a good example of a reasonable password policy. The justification for the policy being created was to make sure that only authorized users could use the protected systems. Sounds like a good idea, but here’s the hard question.

**Why?**

There are a bunch of questions that arise from this policy.

- Why 8 characters instead of 6?
- Are 9 characters twice as secure, or should we have 10 characters?
- Is each of the decisions in that policy justified?
- What is the real goal behind the policy?
- Are you accomplishing that goal in a mathematically provable manner?

To clarify the problem, let’s re-frame the justification behind the policy. Let’s be more specific in the question we want to answer. As an initial question, let’s try something like…

**How do we prevent an attacker with a budget of $10,000 from successfully using the account credentials if they are stolen from a host in an encrypted format?**

Thus we have an attacker with a budgetary limit of $10,000 to provide us some scoping boundaries, since we can’t realistically defend against a determined adversary with an unlimited budget. As for why $10,000? I chose this amount as a reasonable amount of money a dedicated attacker would spend to build a capability that could be re-used against multiple targets. So, now we have a maximum 90-day time limit for the attack to be successful based on the password rotation policy. Lastly, we have a threat model against which we can measure the success of our policy changes.

So, what is possible with that budget? An Attacker could buy a pre-configured 8 GPU card system designed for cracking passwords at a rate up to 102.6 BILLION attempts per second for MD5 hashes but that would cost approximately $20,000.

Using the same NVidia GeForce GTX 980 GPU in a graphics card as the pre-configured system, an attacker can spend $5,000 on GPUs, $2,000 on a server to hold them, $1,000 on hard drives, and still have a couple thousand left to buy some nice monitors and a comfy chair.

On the defender side of the equation, we can start looking at a standard server running RedHat Enterprise Linux 6.6, which uses the default hashing algorithm of a salted SHA-512 password hash to store the hash in /etc/shadow, against which the maximum speed our $10,000 adversary can try to brute-force a password is 4,005.9 MH/s or 4.0 billion hash attempts per second. Note: this ratio of attempts per second is extremely large due to the ability to use the GPU (Graphics Processing Unit) as a computational booster for the computation.

Then we can continue by looking at the standard US keyboard, where we have the following…

- Uppercase = 26 choices
- Lower case = 26 choices
- Numbers = 10 choices
- Special characters = 33 choices

If we begin with the assumption that our users are choosing completely random strings that satisfy the password complexity requirements, this gives the user 95 possible character choices for each of the required minimum eight characters.

95 x 95 x 95 x 95 x 95 x 95 x 95 x 95 = 6,634,204,312,890,620

Note: We know this assumption is a bad idea, but will address this issue later. For now, let’s examine the best case scenario.

Thus the maximum length of time that the attacker could try to brute force guess every possible combination of characters for the minimum eight characters at their 2.2 billion SHA-512 hashes per second would be.

6,634,204,312,890,620 / 2,207,700,000 = 1,656,108.31845 seconds

or

0 years, 19 days, 4 hours, 2 minutes, 48 seconds

Thus, within less than twenty days of the password file being stolen, the adversary could try all 6 quadrillion possible combinations of input and thus would know every single account credential with the minimum acceptable length of an 8-character password that was encrypted by SHA-512. Of course, some users may use a longer than 8-character password, and thus their account credential might not be compromised, but others would not be so lucky.

So, what is the real question you want to answer? I think a better question than “Why is this your password policy?” could be…

**How many characters should a password be, so that an adversary with a $10,000 budget could not brute-force any passwords from a list of 10,000 users and be able to use them before they expire in 90 days?**

If we continue to assume that our users are choosing completely random strings that satisfy the password complexity requirements, then the math is quite simple. Looking at a chart of cracking speed vs. password length we see that just one character makes the difference between nineteen days and five years.

Hashes cracked per second | 4,005,900,000 | |

Length of password | Maximum number of possibilities | Length of time to crack |

1 | 95 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

2 | 9,025 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

3 | 857,375 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

4 | 81,450,625 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

5 | 7,737,809,375 | 0 years, days, 0 hours, 0 minutes, 2 seconds |

6 | 735,091,890,625 | 0 years, days, 0 hours, 3 minutes, 4 seconds |

7 | 69,833,729,609,375 | 0 years, days, 5 hours, 51 minutes, 33 seconds |

8 | 6,634,204,312,890,620 | 0 years, 19 days, 4 hours, 2 minutes, 48 seconds |

9 | 630,249,409,724,609,000 | 5 years, 361 days, 23 hours, 52 minutes, 30 seconds |

10 | 59,873,693,923,837,900,000 | 474 years, 345 days, 12 hours, 33 minutes, 54 seconds |

11 | 5,688,000,922,764,600,000,000 | 45,025 years, 336 days, 17 hours, 6 minutes, 34 seconds |

12 | 540,360,087,662,637,000,000,000 | 4,277,367 years, 138 days, 16 hours, 48 minutes, 15 seconds |

13 | 51,334,208,327,950,500,000,000,000 | 406,349,901 years, 303 days, 13 hours, 55 minutes, 2 seconds |

14 | 4,876,749,791,155,300,000,000,000,000 | 38,603,240,579 years, 273 days, 14 hours, 3 minutes, 40 seconds |

15 | 463,291,230,159,753,000,000,000,000,000 | 3,667,307,854,981 years, 306 days, 22 hours, 26 minutes, 8 seconds |

But, humans don’t choose random passwords; they only choose a small subset of the possible passwords, so the attacker has a much smaller search space to attack. Furthermore, we can look at some of the research that has been done to get some background on the problem

- Using Probabilistic Techniques To Aid In Password Cracking Attacks - Charles Matthew Weir
- A Large-Scale Study of Web Password Habits - Dinei Florêncio and Cormac Herley
- Password Cracking Based On Learned Patterns From Disclosed Passwords - Hsien-Cheng Chou, Hung-Chang Lee, Hwan-Jeu Yu, Fei-Pei Lai, Kuo-Hsuan Huang and Chih-Wen Hsueh
- Password Strength: An Empirical Analysis - Matteo Dell’Amico, Pietro Michiardi and Yves Roudier
- Guess again (and again and again): Measuring password strength by simulating password-cracking algorithms - Patrick Gage Kelley, Saranga Komanduri, Michelle L. Mazurek, Richard Shay, Timothy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio López
- An Administrator’s Guide to Internet Password Research - Dinei Florêncio, Cormac Herley, Paul C. van Oorschot

From the different research done in these papers, we can extrapolate that an attacker could theoretically increase their attack speed between 175 and 250 times faster through using a large dictionary with aggressive pattern mutation rules. Since we are taking a conservative approach in our policy let’s take the higher value and re-run our brute-force analysis for a single password hash recovery.

Hashes cracked per second | 4,005,900,000 | |

Length of password | Maximum number of possibilities | Length of time to crack |

1 | 95 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

2 | 9,025 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

3 | 857,375 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

4 | 81,450,625 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

5 | 7,737,809,375 | 0 years, days, 0 hours, 0 minutes, 0 seconds |

6 | 735,091,890,625 | 0 years, days, 0 hours, 0 minutes, 1 seconds |

7 | 69,833,729,609,375 | 0 years, days, 0 hours, 1 minutes, 10 seconds |

8 | 6,634,204,312,890,620 | 0 years, days, 2 hours, 50 minutes, 24 seconds |

9 | 630,249,409,724,609,000 | 0 years, 7 days, 7 hours, 49 minutes, 41 seconds |

10 | 59,873,693,923,837,900,000 | 2 years, 327 days, 23 hours, 5 minutes, 10 seconds |

11 | 5,688,000,922,764,600,000,000 | 180 years, 36 days, 9 hours, 11 minutes, 18 seconds |

12 | 540,360,087,662,637,000,000,000 | 17,109 years, 171 days, 9 hours, 54 minutes, 23 seconds |

13 | 51,334,208,327,950,500,000,000,000 | 1,625,400 years, 220 days, 5 hours, 48 minutes, 19 seconds |

14 | 4,876,749,791,155,300,000,000,000,000 | 154,412,962 years, 115 days, 5 hours, 3 minutes, 56 seconds |

15 | 463,291,230,159,753,000,000,000,000,000 | 14,669,231,420 years, 303 days, 9 hours, 22 minutes, 8 seconds |

Thus, we can make a determination that with a completely random password with a minimum 12 characters that the probability of a hash collision in a file with 10,000 different user passwords, that a single user’s password found by the attacker is 1 in 69,387 chance or a 0.00144% chance of a collision.

Therefore the minimum number of characters needed to ensure that a password consisting of upper and lower case letters, numbers, and special characters that is hashed by the standard SHA-512 is not compromised within a 90 day window is… **12 characters.**

Now, when asked about our policy we can show justification for this decision, back it up with proof, and provide metrics to measure its’ success.

**Conclusion**

So, we started trying to explain what is Security Science, with the examination of password policy, a staple of Information Security best practices, we then looked at only one of the decisions in that policy and tried to gain measurable insights against it. We then could make a tangible suggestion based on the insights to achieve the desired outcome.

Additionally, while working on this post, we also uncovered new topics to cover in future work.

**How can the choice of a hashing algorithm change the overall security of a system?**

**What are the benefits when using a multi-factor authentication method instead of passwords?**

**What is the maximum number of passwords that a human can keep track of and the maximum frequency of change they can handle?**

Security Science is the use of data analysis and scientific rigor to provide insights to help steer security decisions to a logical fruition.