Why We Recommend Your Passwords Be Over 20-Characters Long

RogerMasterClass-FeatureImage (1) (1) KnowBe4 just released its official guidance and recommendations regarding password policy. It has been a project in the works for many months now, but we wanted to make sure we got it right. Here are our official password recommendations:

KnowBe4-password-policy-recommendations

The summary of our recommended password policy is:

Use phishing-resistant MFA where you can

If you cannot use MFA, then:

Use a password manager to create long and complex passwords wherever you can
If you must create your own passwords, make them 20-characters or longer

The optimal recommendation is a scenario where everyone would have one or two human-created long passphrases/passsentences, if needed, and use a password manager or MFA for everything else. The human-created passphrases/passsentences would be the ones needed to log into your device(s) and your password manager (if needed for those instances).

Our Recommendations vs. NIST’s Recommendations

We know a lot of readers are cringing at the idea of having to create 20-character passwords to be truly secure, especially in light of some other official guidance from the National Institute of Standards and Technology (NIST), from 2017, the Digital Identity Guidelines saying that long and complex passwords are not needed.

NIST said this because it is a known fact that most attacks against passwords (e.g., social engineering, theft and bypass) do not care what your password is. A hacker can trick someone out of their very long and complex password as easily as a simple password and malware and hackers can steal either type with equivalent effort. Because most password attacks do not care how long or complex your password is and because users being forced to create many long and complex passwords are far more likely to reuse the same ones across multiple websites and services, which is a far greater risk to most organizations. NIST recommends no official minimum password length, no required complexity and even no forced mandatory password changes.

NIST’s new advice (new as in published in 2017), went against all their previous advice, and against most of the world’s conventional understanding of what passwords had to be to decrease cybersecurity risk. It was such a controversial moment that still, over 5 years later, most regulatory guides and requirements do not allow short, non-complex and never changing passwords.

We do not recommend NIST’s password policy recommendations either. Let us explain why.

NIST is right, people who have to create long and complex passwords will be incentivized to reuse them across multiple unrelated sites and services. We do not want people to have to create long and truly complex passwords either, even though it is the best thing they could do risk-wise, if they would do it.

The only two attack scenarios where the length and complexity of a password are important are guessing at the password (usually within an online login prompt) and password hash cracking. The rate at which an attacker can guess at a particular password in an online attack is limited by the how many guesses the attacker can make in a particular time period. Oftentimes, password guessing is limited by some sort of rate-throttling mechanism, like account lockout, where after too many bad guesses, the involved account is locked out (either for a pre-set period of time or until someone unlocks it). In many networks, password guessing against a user account might be limited to only a handful of guesses every 15 minutes. But there are many scenarios where attackers have been able to guess at an almost unfettered speed approaching over 100,000 times a day.

That sounds like a lot of guessing, and it is, but a 12-character, human-created password with complexity guessed at on an online portal starts to become difficult for even unfettered attackers to successfully guess unless they are given a very long period of time (e.g., over a year) to do that unfettered guessing. But to be more secure against password guessing, you should go longer. A truly, perfectly random password becomes unguessable at around 11 characters, even if the attacker is allowed to guess trillions of times a second for decades.

With password hash cracking, the attacker has been able to previously obtain the potential victim’s password cryptographic hash (which takes one or more additional exploits) and then the hacker uses a very fast password hash guessing solution to try to guess at the plaintext password given the password’s hash. There are many password hash cracking “rigs” which can guess at many trillions of guesses a second. There are likely many hundreds of attackers with the local capability to guess at hashes at tens of trillions of guesses a second and that sort of capability can be purchased from many different cloud vendors for fairly cheap sums. The highest speed existing password hash cracking rigs are thought to be at the 100 trillion guesses per second. Could your password/password hash survive if guessed at many trillions of times a second? Most people’s passwords would not stand for very long.

But again, a truly, perfectly random password becomes unguessable at around 11 characters. So, we recommend 12-character perfectly random passwords to defeat all currently known password guessing and cracking attacks.

We, like NIST, do not want people creating long and complex passwords. We believe that the truly, perfectly random passwords created by password managers are easier to use and better decrease risk than most human-created passwords. That is why we recommend that users use a trusted password manager to create and use perfectly random passwords, wherever possible, wherever phishing-resistant MFA cannot be used.

NIST knows about super-fast password hash cracking rigs, too, as well as password managers. So, why does NIST not also recommend MFA and password managers? First, they do recommend using MFA and allow it to be used on all levels of systems. They do say in NIST SP 800-63 to avoid using MFA connected to phone numbers (e.g., SMS-based or voice-based MFA) for anything but the lowest level systems.

NIST does not explicitly mention password managers (at least in NIST SP 800-63 and other authentication-related documents I can find), but they do recommend very high entropy (i.e., highly random) passwords dozens of times, which password managers are uniquely suited to. NIST is generally dismissive of passwords (and PINs) completely, regardless of entropy and make-up, except for the lowest value systems. It is clear that NIST wants defenders to move away from password-based authentication because of all the threats and attacks against them.

However, the biggest reason we disagree with NIST’s more relaxed password recommendations is that password hash theft and cracking has become a bigger threat than ever before. Yes, password theft attacks are a far greater percentage of attacks, and with those attacks, your password length and complexity do not matter.

But we strongly believe that NIST did not consider the relative risk of password hash theft on the overall security risk of most organizations. In a nutshell, password hash theft and cracking has become easier to do than ever. And if an attacker can gain access to your device and/or network, it really is game over for any human-created passwords shorter than 20 characters, especially if running on a Windows device or network. Let’s explain more.

Password Hash Theft Methods

Traditionally, when someone types in their new password for the first time into an operating system (or applications that utilize password hashes), the plaintext password is converted to a cryptographic hash representation of that plaintext password. It is that password hash that is stored within the operating system, usually in files located locally or on the network, and that are used in authentication. Attackers getting the hashes don’t get access directly, right away, to the user’s plaintext password, but access to the password hash they can begin trying to crack it back to the plaintext password.

Traditionally, in order for an attacker to get someone’s password hash, they had to somehow obtain super elevated administrator or system access to the operating system and then go to the password hash storage files or run a script or tool to obtain the hashes. It took the attacker getting super admin access to begin the password hash crack process. And although hackers routinely get this level of access on people’s systems tens of thousands of times a day, it at least presented some minimum bar that had to be crossed first, before the attacker could begin to try and convert hashes into their related plaintext passwords. And once hackers had super elevated admin access, really what could they not do? They could do anything that was programmatically possible on the compromised system, including simply do away with the need to use passwords at all. It is game over!

Kerberoasting

But it turns out there are at least two, if not more, methods a hacker can use to obtain someone’s password hash without being super elevated. The first is known as Kerberoasting. With Kerberoasting, an attacker, with access on a Microsoft Active Directory network, can use any regular user account and extract the password hashes of any account with a Kerberos service principal name (SPN). The definition of an SPN is not important. Just know that many of the most elevated accounts (e.g., service accounts) have SPNs, which means an attacker breaking in as any type of normal user (on a Windows network) can often easily get the password hashes for one or more elevated accounts, and from there, quickly take over the rest of the network.

This is not a theoretical risk. It is done by real world hackers every day. It is done by professional penetration testers every day. It is done by ransomware gangs every day. It was not so common back in 2017 when NIST issued their official password policy advice. It was known how to do it (e.g., Kerberoasting) back then, but almost no one did it and there was not nearly as many tools to do it. Today, many hacking groups routinely do it and there are dozens of tools and scripts dedicated to doing it. Colloquially, it is child’s play.

But at least with Kerberoasting, the attacker needs to compromise at least one regular user account first to begin the attack. There is another password hash theft method that does not require that the attacker have first compromised any other account and can be performed remotely over the Internet. The author of this article first wrote about this real-world password hash attack in 2019.

Captured Password Hashes via Email

In a nutshell, an attacker can craft a malicious URL link, present it to a user, and if the user clicks on it, it will often lead the victim’s email client or browser to expose the user’s password hash. The attacker can then take the hash and crack it back to the user’s plaintext password. No special privileges needed. The attacker does not even need to be on the victim’s network. The attacker can send a simple-looking email, which if the victim clicks on, it causes their password’s hash to be sent to the attacker.

When I first wrote about this attack, which had already been around in the real world for a few years, it was not used in the real world much. It was used, but really only by a handful of hackers and even then, fairly sparingly. Since 2019, it has become mentioned in more and more real-world attacks, including these:

This is to say that it is no longer a rarified attack, if it ever was.

Because people’s password hashes can be obtained more easily than ever, especially on Windows devices and networks, any organization that wants to have what the computer security world considers “strong” computer security, should create passwords which are resistant against password hash cracking attacks. That means 12-character or longer perfectly random passwords or 20-character or longer human-created passwords. And because no one really wants to have to create and use a bunch of really long passwords, we recommend using phishing-resistant MFA and/or password managers whenever you can.

That is it. This is the reason for our recommendation of 20-character or longer passwords when created and used by a human. Anything shorter just is not secure enough, especially if you are working on a Windows device or network. Maybe one day Microsoft will make it far more difficult for their password hashes to be stolen and cracked in the first place (and they are trying, but it takes a long time to change a big ship’s direction).

Feel free to send any questions or comments you have to rogerg@knowbe4.com

E-Book: What Your Password Policy Should Be

In this e-book, Roger A. Grimes, KnowBe4’s Data-Driven Defense Evangelist, details the pros and cons of password use. Roger explains how the implementation of supporting frameworks, such as MFA and password managers, can help you keep your organization locked down.

Download this e-book to learn:

What tactics bad actors use to hack passwords (and how to avoid them)
The pros and cons of password managers and multi-factor authentication and how they impact your risk
How to craft a secure password policy that addresses the most common methods of password attack
How to empower your end users to become your best last line of defense