This post is Part 2 of our reaction to recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63b), 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 Monster, 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 NIST 800-63B Special Publication suggests that organizations allow passwords of at 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? Notice particularly that the time to crack the first password, which is more complex but shorter, is much shorter than the time to crack the second password, which is less complex but longer. 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; We’re * 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 and 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.). This makes it much simpler to calculate the number of possibilities. The formula is *n ^{k}*, where

*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. That means a standard 8-character password without special characters has almost 3 trillion possibilities. By adding special characters, we can add another 33 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 (shorter) 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, we’d say this particular NIST recommendation makes plenty of sense for users.