## The Great Password Debate (Part 2): Longer, Simpler Passwords Are the New Black

September 8, 2017 at 4:03 pm | Posted in cybersecurity, Knowledge, Technical Tips | 4 CommentsTags: Appendix A, complexity, cybersecurity, memorized secrets, NIST, passwords

This post is part two of our reaction to new recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63), Appendix A – Strength of Memorized Secrets. You can check out Part 1 here.

Which of the following two passwords is more secure?

`p@$w0RdCh34Tr#`

`ILikeSimplePasswordsICanRememberAndUseNotComplex`

The first password is 14 characters long, well over the recommended minimum of 8 characters. It also meets many, if not all, of common password complexity requirements: it contains multiple special characters like @ and $, numbers like 3 and 4, and mixes uppercase and lowercase letters in for good measure. It does not contain a username or any repeated characters. At the Password Meter, I get the following rating:

The second password is a lot longer (over 3x), clocking in at 48 characters. If you think that is crazy long, section 5.1.1.2 of the new NIST 800-63B Special Publication suggests passwords of least 64 characters! But this password is pretty awful when it comes to complexity: it has no special characters or numbers, and it contains easy-to-read dictionary words. So you’d expect a really low score from the Password Meter.

But you’d be wrong:

What is going on? In a nutshell, according to the latest research, password size matters more than character complexity, even if the password strings together easy-to-read words. This is a harsh truth, to be sure, and the reason why requires a quick trip back to mathematical set theory and the world of bike lock combinations.

Do not trouble your hearts; I’m ** not** going to delve deep into set theory. Rather, let’s skip straight to the practical applications of combinations. Take the following bike lock combination:

The length of this “password” is 4 characters. limited to numbers only. If we could only use each digit once, then we could call this a *permutation*. But this is a *combination*, like most passwords, which allows the same digit to be reused (8867, 9978, etc.) and much simpler to calculate the number of possibilities. The formula is `n`

, where ^{k}*k* is the number of slots and *n* is the number of allowable options for each slot. So, in this case, the number of possible combinations is calculated as follows:

`10`

^{4} = 10 * 10 * 10 * 10 = 10,000

This would take a human some time to run through every combination, but there are shortcuts like the tug method (and of course, a good pair of bolt cutters) that can drastically reduce that. But for the sake of argument, let’s assume a human would probably average around a second just chugging away at every combination, meaning it would be close to 3 hours to crack the lock. A modern computer would be in the tenths of a millisecond range, but might be slower only because of having to physically move the combination dials.

Now, let’s see what would happen if we added an option for a special character. What would that do to our number of combinations?

`11`

^{4} = 11 * 11 * 11 * 11 = 14,641

That is almost a 50% increase! Assuming a standard rate per guess, that would also increase the average cracking time by the same amount – roughly 4 hours for a human. But a computer would still be under a millisecond.

Okay, what happens if we add another combination dial, increasing the number of slots to 5? What would that do to our number of combinations?

`10`

^{5} = 10 * 10 * 10 * 10 * 10 = 100,000

The increase is dramatic – 10 times the number of combinations, growing it by an order of magnitude! It will now take a human over a day to go through every combination, and the computer is finally breaking a sweat, going over a second to crack it.

Okay, sounds good, but how does this apply to normal alphanumerical passwords? Well, first using only letters (uppercase and lowercase) and numbers gives us an *n* of 62 possibilities. By adding special characters, we can add another 33 possibilities. That means a standard 8-character password without special characters has almost 3 trillion possibilities. If we factor in special characters, then the number of combinations goes past 513 trillion. But if we extend the password length by just two alphanumeric characters instead without special characters, then the number of combinations rolls up to over 3 quadrillion!

So, prior to advanced password cracking utilities and their shortcut algorithms, adding a single character to a password could increase standard cracking time by another timescale. If it takes hours to crack an 8-character password, it would take days to crack a 9-character password.

Let’s go back to our previous examples of `p@$w0RdCh34Tr#`

and `ILikeSimplePasswordsICanRememberAndUseNotComplex`

.

The first password contains a common substitution/misspelling of the dictionary words *password* and *cheater*. Although this password is not ideal, it still may take over 2 months for a dedicated cracker machine to break it. And most of that’s really due to length, not complexity, anyway.

The second password contains 11 words, easily found in any dictionary. But the sheer number of characters and unpredictable combination of those words (at least for a machine) will take over 84 trillion millennia to crack! Now, that is some staying power – outliving users and their progeny many times over.

In summary, the numbers show that a standard password that meets the common “complexity rules” can be broken in a matter of months, while a longer string of common dictionary words would (mathematically speaking) take hundreds of trillions of years to crack. So, just based on the numbers, I’d say this particular NIST recommendation makes plenty of sense for users.

What do you think? Let us know in the comments below.

Joshua Hester

## 4 Comments »

RSS feed for comments on this post. TrackBack URI

[…] This post is part three of our reaction to new recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63), Appendix A – Strength of Memorized Secrets. You can check out Part 2 here. […]

Pingback by The Great Password Debate – Why we disagree about password resets and failures (Part 3) | Transcender IT Prep Blog— September 20, 2017 #

How is it you can get yourself into a position to dictate and set password requirements, yet not understand this! It would simultaneously make passwords easier for people to remember, and more difficult for computers to crack. Maybe it’s just too “simple”. 🤔

Comment by Anonymous— November 30, 2017 #

I could not agree more. But human nature is to take a simple problem and over-solve it with technological complexity.

Comment by codeguru— November 30, 2017 #

A win-win! Make passwords easier for people to remember and more difficult for computers to crack.

Comment by db— November 30, 2017 #