When I worked in the US Department of Defense, our computer systems had password requirements that were the stuff of legend. 3 lowercase letters, 3 uppercase letters, 3 numbers, 4 special characters, and they had to be at least 16 characters long. Plus they had to change every 30 days, and couldn’t be one of the last 25 passwords used. Because these were the requirements for our primary system logins, there was no chance of using a password manager.
So how did people handle this? Everyone diligently memorized the new password every thirty days, thankful that there were policies keeping everything secure, right?
Of course not!
Everybody kept their password on a sticky note stuck to their monitor where it could be viewed by anybody walking past. And the technical people who understood the risks of their password getting compromised? Well, they took a more sophisticated approach like tucking the sticky note in a desk drawer where it would take at least 30 seconds for someone else to find.
I worked with somebody at the time who – and this is completely serious – would dedicate an hour once a month to go through and change their password 25 times in a row so that they could keep the same password. Stupid, or genius? I’ll let you decide.
It was extremely apparent to everybody who actually used the system that these password requirements, all in the name of security, made the system less secure. Passwords that met those requirements were in fact relatively good passwords, but human nature wasn’t accounted for at any point along the way.
That same job had a web-based system that could only be signed into using an on-page keyboard launched as a java applet, but the keys were in random order each time. Apparently, the DOD was very afraid of keyloggers and, I don’t know, some nefarious system that could reliably detect where somebody clicked on a screen to enter a password?
Oh – and if you had to reset your password in that system, a new one came IN THE MAIL. Yes, somebody somewhere licked a stamp to get your new password to you.
I am sure you have come across user-hostile, or just plain bad password policies in your time. When setting up an account, maybe you’ve been told:
- “The password must be between 10 and 12 characters long”
- “Your password must use one of the following special characters: -!&]’*”
- “You must have either 2 uppercase characters OR 4 numbers OR 3 special characters in your password”
- “Spaces are not allowed in your password”
If you want to have fun cringing at some good examples of bad approaches, there is a Tumblr just for you: https://badpasswordpolicies.tumblr.com
Unquestionably, we need good passwords. The problem is that password policies and requirements often do little, if anything, to actually make the authentication system more secure. They might even actually drive users away from your business, or encourage practices that actively reduce security (like writing their password on a post-it affixed to their monitor).
To better understand how to build a good password policy, we need to look at human nature. In a word, humans are LAZY. A more charitable word might be “efficient”, but we all look for the path of least resistance. Most people don’t understand or care about security, and password policies should reflect both this laziness and lack of understanding.
The NIST (National Institute of Standards and Technology) publishes guidelines on password policies which are frequently referenced by Amazon, Microsoft, and others in the documentation for users of their products and services. Luckily their guidelines are mostly based on common sense, or the logic behind them can be grasped with a basic understanding of how passwords are stored and used by authentication systems.
Some approaches you can take with a modern password policy include:
Require long passwords
Password length is the single most important factor in keeping passwords secure. Over-simplifying a little bit, generally the longer a password is the longer it takes for a computer to “guess” it.
If your password is “1234” and a hacker is using an automated system to try and guess your password when they have the hashed version in hand, how many attempts do you think it will take?
What if your password is a single dictionary word? How many attempts will it take to guess your password? There are about a million words in the English language, so all else being equal we can say that on average it would take about half a million attempts. How quickly would your single English word password be found out?
The answer may surprise you – but if a hacker got your hashed password they can check every single word in the English language against your password in 1/100,000th of a second! The numbers are mind-boggling. And that stat is from 5 years ago as of this writing, so hardware has gotten only more powerful. The ability to use the cloud to distribute workload like this means that practically speaking, a determined hacker with some resources could try hundreds of trillions of combinations per second as they try to crack a password.
You can take the worst password in the world and add the phrase “pumpernickleresurgence” on the end of it, and you will instantly have a password that would require significant time and resources to crack. No special characters, no numbers, no mixed-case letters, etc.
There are several places on the internet that can help you evaluate how good a password might be. Don’t trust the sites enough to put real passwords in there – but they can help you understand relative password strength. For example, we see the following brute-force cracking estimates for the following passwords from Kaspersky:
- 123 – instantaneous
- 123456789 – instantaneous
- H@ppyG0Luckee – “Less time than it takes to get back from a walk”
- gI83^bs@4l;0) – “Less time than it takes to get back from a walk”
- 123pumpernickleresurgence – 1600 centuries
Does the difference between gI83^bs@4l;0) and 123pumpernickleresurgence surprise you? The simple fact is, we’ve been trained to think about password strength in the wrong way because of all the terrible policies out there.
Don’t require complexity
The NIST recommends against having any complexity requirements at all, and current guidelines recognize that those requirements generally do more harm than good.
Complex passwords are certainly better than simple ones. A good mix of numbers, special characters, uppercase/lowercase, and special characters does make a password stronger, although length is still most important. The problem enters when this complexity is required.
One reason is that most forced complexity is easily guessed. For example, if you require a number there is a good probability that a user will just add “1” to the end of whatever they were using. Most critically, requiring a complex password increases the probability that users will reuse them between systems. Since Adobe, LinkedIn, and Marriott have had hackers gain access to hundreds of millions of passwords, you need to consider that it can happen anywhere. And if somebody used a password in one of those systems, you definitely don’t want it reused in your software.
Don’t require periodic changes
One of the worst and most illogical elements of enterprise security theater is requiring periodic password resets. Think about it – if a hacker gains access to a user’s account, they are going to do what they are going to do and get out. Or for access to key systems, they are going to enable some other form of access and cover their tracks.
All that these reuse requirements do is frustrate users, so when passwords are required to be periodically reset, subsequent passwords are generally very predictable – the “1” at the end becomes “2”, etc.
NIST recognizes this form of pointless user hostility and recommends never requiring password changes.
A few other items worth mentioning
Password policies, as part of a comprehensive security strategy, are important. Unfortunately, many enterprise password policies are completely out of date and based on inaccuracies or misunderstandings about password security.
This is a simple blog post, not intended to explain everything about passwords and security. Instead, I hope that poking some fun at bad policies and illuminating more modern thinking can get conversations started about organization-level improvements. A good discussion should consider different standards for different systems, multi-factor authentication, and even things like key-based logins for core, critical systems.
If you are actually responsible for ensuring that a system is properly storing and processing passwords, there is a lot more to be aware of. If you don’t want to wade through the actual NIST document referenced above (I don’t blame you!), there are several summaries and starting points available including this one from Auth0.
You should also think about how to protect yourself with all the accounts we have to create all the time. You can’t control whether your password is stored securely – but you can take steps to make sure any problems with one site is minimized to just that site:
- Always use a new password with each new login – never re-use a password between services.
- Use a password manager. You won’t remember all your passwords between sites, so you need something that can do it for you. There are lots of good options out there; I personally use Bitwarden, but it might not be the best option for your situation.
- Keep your passwords long. If you are using a password manager you can use passwords that are 20+ characters long, and completely random.
Next time you come across a system that warns you that your 24 character password isn’t secure because it doesn’t have the right combination of numbers and special characters, feel free to roll your eyes as you figure our what particular combination this systems wants – and just pull up your password manager, help it give you a password that meets the requirements, and move on.
And if you are responsible for a password policy somewhere out there that is making users miserable for reasons that are now recognized as outdated? You have a chance for the win-win of making your system more secure AND helping your users curse the system just a little bit less.