What is the right password policy? Conventional password policies say you must have a password at least 8-12 characters long…16 characters or longer if it belongs to an elevated privileged account, contain letters, numbers, and symbols (making the password complex), and be changed every 90 days or less. That’s the password policy we‘ve been taught we need to have for 30 years.
Then in 2015, the National Institutes of Standards & Technology (NIST) changed all of that guidance…their own previous guidance…when they released NIST Special Publication 800-63, titled the Digital Identity Guidelines. With SP 800-63, NIST declared that using the old password policy would actually make you more likely to be compromised because of that advice compared to if you didn’t follow it at all. Wow!
Now NIST is saying you shouldn’t require long and complex passwords (6-8 characters is fine, artificial complexity is not needed) and they don’t need to be changed unless you know they are compromised. This is essentially the defacto password policy that the computer security world considered as super-weak password policy and spent the entirety of the previous three decades trying to get organizations off of. Now NIST is saying their new advice is better than having long and complex passwords that are frequently changed.
To say this surprised and confounded the computer security world would be an understatement. The new advice is so distrusted that nearly no organization follows it…other than the people and entities that never moved to the traditional advice in the first place. Most public websites have never required that people have long, complex, and frequently changing passwords. Nearly everyone has the same Amazon, Facebook, and Twitter password since they first signed up.
But on the corporate and government side of things, most organizations have been following the traditional password advice for the past decade and it’s become so ingrained, security-wise, that almost no one wants to give it up. You’ll have to pry it out of their “cold, dead, hands”, so to speak. Not a single national computer security policy recommendation or guideline (e.g., PCI-DSS, DISA STIGs, HIPAA, SOX, NERC, CIS, etc.) has updated their password policy advice to follow the new, recommended NIST advice. The only related acquiescence I can find relating to what NIST is now pushing was Microsoft changing their recommended password policy default to none, essentially saying it is up to the administrator of each deployment to decide what their password policy will be.
Why Did NIST Change Its Recommendations?
NIST researchers looked at decades of real-world password hacks and determined that most attacks involving passwords don’t involve guessing or cracking, which is what password policy is created to mitigate. Guessing passwords is when someone or an automated tool tries different possible password combinations against a login portal to see if they can arbitrarily guess the correct password. Password cracking means an attacker has previously obtained an obfuscated form of the password, like the password’s cryptography hash representation, and uses automation of some sort to convert the obfuscated form of the password to its plaintext equivalent.
Early on, decades ago, password guessing and cracking comprised the majority of password attacks. Today, that is no longer true. In most cases, people’s passwords are stolen (using phishing and social engineering or from compromised password databases) or the password hashes are used in authentication without the need to convert to the plaintext equivalent (known as Pass-the-Hash attacks). NIST researchers determine that when people are forced to use long, complex, and frequently changing passwords, that they reuse them between different websites and services, which significantly increases the chances of compromise from that password policy use. Instead, NIST recommends the use of multifactor authentication and when passwords are used, that they not be long, complex, or frequently changed. Instead, they recommend that the passwords not be from a list of very common passwords and not be easily guessable (however that is determined).
On the other side, there are many hackers (or their malware creations) which are still finding great success with shorter, weaker passwords. For example, many ransomware programs use password guessing against Remote Desktop Protocol (RDP) sessions to break into computers. In this article, it says that 30% of all successful ransomware exploitations happened because of weak passwords.
This blows my mind in one way…I can’t believe people are still using passwords that can be guessed by others or malware. At the same time, after analyzing various stolen passwords (available in public repositories) over 30 years, I’ve also seen that way too many people use the same common passwords. For example, the 2019 United Kingdom National Cybersecurity Centre annual review said the fourth most common password is password. The first, second, and third most popular passwords? 123456, 123456789, and qwerty. You can’t make this stuff up. And it’s been this way for decades.
To be fair, NIST’s “relaxed” password guidance specifically says vendors and administrators should not allow users to use easy to guess passwords, so whether you are using the new NIST recommendations or the traditional password policy, you should be covered. The problem is that most password authentication systems don’t have the logic to be able to stop people from choosing weak passwords, like qwerty or 123456. Instead, what they do is require password complexity. Requiring passwords to contain letters, numbers, and symbols assures that people will not use the simplest of all passwords (although you can still do p@ssword1 to fulfill the complexity requirement). Requiring complex passwords is the easiest way to prevent people from using super simple passwords…and I can’t argue with that.
NIST’s Biggest Problem With Passwords
It’s important to note that NIST’s main problem with traditional password policy isn’t that passwords are or aren’t complex. Clearly, NIST cares about people not using easy to guess passwords, too. Their problem is that when long and complex passwords are also used with forced password changes that most people reuse across multiple, unrelated sites. And this is true. Most people use the same four to eight passwords across every password-protected site and service they have, which is often over 100 different sites. The reuse means that a compromise of one site can lead to the compromise of a bunch of different sites. This is NIST’s main problem with traditional password policy – that the forced changes encourage reuse, especially when complexity and long length are required.
So, Never Change Passwords?
NIST recommends that passwords never be changed unless you think/know they have been compromised. This is where I have screeching disagreement with the NIST guidelines. Most of the people whose passwords have been compromised didn’t know for a long time, if ever. There are many billions and billions of people’s logins and passwords out on the Internet and most of those people don’t know it…and they are publicly available for anyone to check! Most password thefts are done in secret. The attackers don’t want people to know or sell the lists in private forums. The number one argument for periodically changing a password is that most people don’t know when their passwords have been compromised. So, too offset the risk, organizational passwords should be changed at least once a year, if not more often depending on the organization’s risk tolerance.
But this recommendation leads us right back to what NIST was trying to avoid in the first place. If organizations require long, complex, and frequently changing passwords, doesn’t that actually increase risk and not lower it? Yes, according to NIST. But I haven’t seen any of the details or facts to back that case. I’ve heard that NIST researchers have concluded that fact, but I haven’t been able to confirm it. I’ve written to NIST and many NIST researchers asking for the data behind their conclusion and I haven’t been able to get any. That bothers me. Ultimately, I would not want to follow NIST’s new advice unless I could see transparent, objective, unbiased data that supports their conclusion – i.e., that the risk from long, complex passwords that are frequently changed is greater than shorter, non-complex passwords that never change.
On top of that, we know that 30% of ransomware attacks are because of easy to guess passwords.
That’s a pretty huge risk! And requiring long and complex passwords offsets that risk. And periodically changing passwords offsets another huge risk. I don’t want a password compromise of my employee’s passwords from a year ago still being valid against my company. I don’t. I can’t take the risk…at least without easy-to-see evidence from NIST that I’ve got my worries reversed. So, until I see the data from NIST to support their new password policy recommendations, I’m still supporting the old password policy, or actually a slightly modified version.
My Recommended Password Policy for Organizations
Here’s my current password policy recommendations for organizations:
- Use multifactor authentication (MFA) when possible and when obviously needed for security (i.e., you don’t need it for every site and login).
- Where MFA is not an option, use password managers where you can, creating unique, long as-possible, random passwords for each website or security domain.
- Where password managers aren’t possible, use long, simple passphrases.
- Change all passwords at least once a year, and change business passwords every 90 to 180 days.
- In all cases, don’t use common passwords (e.g., 123456, password, or qwerty, etc.)
Most importantly, regardless of your password policy, never reuse any password between different sites!
Sadly, good luck using a computer system to enforce that requirement. There is no authentication system or review that can assure you that your employees and co-workers are not reusing the same password in two different systems. There are some tools and services which can compare an organization’s passwords against known stolen password dumps, but not one that can compare someone’s password in your system to every system they belong to. It doesn’t exist and will likely never exist. Your best mitigation is security awareness training to everyone, which teaches people not to share passwords between sites.
My Biggest Complaint
My biggest complaint with password policies that we likely spend way too much time on them. Overall, even with weak passwords at least temporarily, being involved in 30% of ransomware attacks, exploitations due to password issues is still a much smaller risk when compared to social engineering and unpatched software. Phishing as social engineering is responsible for 70% to 90% of all breaches. Unpatched software is involved in 20% to 40%. Together, they account for 90% to 99% of all successful breaches. Everything else added up all together, including password issues, only accounts for maybe, at the most, 10% of all breaches. So if you’re spending days and days debating what your password policy should be, but not also spending days and day improving the controls you use to mitigate social engineering and unpatched software, you’re spending too much time on passwords.
I go around the world speaking to computer security professionals, and they often bring up the big password debate (NIST vs. traditional password policy) that I share above. I dream of the day when I hear people telling me they are spending days discussing how to best mitigate social engineering and better patching, because then we will have our priorities better aligned against the more likely root causes.
So, what’s the best password policy? Concentrating on fighting social engineering and patching unpatched software until you get those two issues addressed to the point that they are no longer the top two biggest issues by far. That’s the better fight.
** Optrics Inc. is an Authorized KnowBe4 partner
Find out how affordable new-school security awareness training is for your organization. Get a quote now.
The original article can be found here: