The Myth of Password Cracking AKA Bad Analysis

Fact: The value of a great test can be negated by inaccurate, or missing analysis. Now onto the myth of password cracking.

 

We’ve all heard the advice to make strong passwords. The myth that the use of multiple character sets is always required to make a strong password is warrantless. When appropriate password length is allowed, then except in extreme security requirements, it doesn’t matter if you use only lowercase, or only uppercase, or only symbols. Typically, the requirement for numbers does more harm than good, but that’s a different topic.

In a nutshell, the myth is that the longer or more complex a password is, the longer it will take to crack it. Why is it a myth? Let me explain by way of analogy. Those of you who know me know that I love analogies. I even have an analogy for analogies. Here goes.

You have a stack of 200 shirts that are visually identical except for a small mark on one of the tags in the collar. It takes about four seconds per shirt to pick it up, inspect the tag, and put it back down into a new stack. How long will it take for the trains to meet in the middle. Sorry, I have been scarred for life by those math questions. Back to the problem at hand. We multiply 200*4 to arrive at the correct answer of 800 seconds (13.3 minutes) to “test” every t-shirt. Ahhh, the best kind of analysis. Data-driven with no bias or variables. Simple but perfect analysis.

Back to our fashion statement. It so happens that you need that one specific t-shirt. How long will it take you to find that t-shirt? I bet you got the answer right. The answer, of course, is that it depends where in the stack the t-shirt is, right? Let’s say the t-shirt is on the bottom of the stack, but you don’t know that. How long will it take to find it? The correct answer is probably 13.3 minutes; I don’t know how many cat videos you watched while searching. But if the t-shirt isn’t on the bottom of the stack, how long will it take to find it? You don’t know, but it’s less than 13.3 minutes.

Now let’s get outrageous!

My old 386 PC with 4 megs of ram and a math co-processor could potentially crack your 50-character password in one hour and three minutes. The one-hour part was waiting for the computer to finish booting. It took 2 minutes and 45 seconds to launch the password cracker, and 15 seconds to enter your password and processes. Yeah, I hear you say, “if you know my password of course you can crack it quickly on a slow computer.” The problem with that assertion is that when I entered your password, I didn’t know it was your password, it was a lucky guess.

I’m pretty sure you’ve figured out the myth. “It will take x number of years to crack” is based upon the assumption that the password is the last one to be tested. In this example I am ignoring a variety of methods which can speed up the process because they aren’t relevant to the concept being discussed.

When someone says the math shows how many possible permutations there are, therefore, it will take as long to crack the password as the time required to test each permutation” they got it wrong.

Just one wrong word, “will,” rendered the analysis incorrect and may have instilled in a false sense of security. Just change the word to “may” and you have an accurate, but likely, incomplete analysis. Let me add a bit of analysis by addressing an implication. If one lucky guess can crack a password in milliseconds, then multi-factor authentication (MFA) may be an extremely good idea. MFA isn’t just for phishing and credential stuffing attacks, it defends against lucky guesses too. Your password might be the 100 millionth one tested, but may still fall very quickly.

Hey, there’s more analysis for *you* to do. Armed with the information about password cracking and MFA, you can now make a more informed assessment concerning the use of passwords with MFA compared to other solutions.

Let’s rein this into the world of security product testing. A test without quality analysis is data, not information. Quality analysis is essential to maximizing the value of test results. Typically, it is up to the tester to provide accurate, insightful analysis, but sometimes data is what you need to perform your own analysis tailored to your environment. When it’s time to perform your own analysis, watch out for the pitfalls of interpretation, such as the myth of password cracking.

On a final note, garbage in -> garbage out. This means that the test must be designed to provide accurate and relevant data for analysis. There are nuances to testing that can make a test look great, but flaws in the methodology, or a failure to properly implement the methodology, will yield misleading results.

I encourage you to check out SecureIQLab tests for quality data and analysis.

Randy Abrams
Señor Security Analyst
SecurieIQLab