How Most Password Policies Make us Less Secure
Password Management is stuck in a time warp
A while ago I wrote an article prompted by an inappropriate vendor requirement and questions from friends and families about good password hygiene. This one is prompted by businesses that continue to make it hard to use good passwords.
We’ve all been there — entering a new password into a website only to be continually prompted to modify it to add some arbitrary combination of letters, numbers and symbols, or to exclude some characters, or to conform to a very specific length.
By now hopefully we all know that re-using passwords across different sites and services is a really bad idea. If you don’t know why, check out the previous article. The easiest way to do this is to use a password manager, and have it create long random passwords for you for each site. I’m continually frustrated by sites that make it harder to do that with the arbitrary restrictions or worse — preventing copy/paste or auto-fill in the password box.
Quick question — if you have to manually type your password in every time are you more or less likely to make it long and complex?
Everyone knows the answer to that question, yet here we are.
It’s not like we don’t know what does and does not work to encourage the right password behaviour. The subject is very well researched, and there are standards bodies that publish best practice guidelines that explain why each recommendation is included and how they can be implemented.
Perhaps the most commonly referred to standard is from the US National Institute of Standards and Technology (NIST). NIST publish password management guidelines that are mandatory for US government departments and highly recommended for everyone else, and they are updated periodically to ensure they keep up with new technology and techniques.
How to Make Passwords Less Secure
Let’s cover some common methods implemented to make passwords secure that actually do the opposite.
First — lets imagine the set of all possible passwords to get us started:
If a hacker has to try to guess your password, or crack it using brute-force techniques after some dodgy site has let them steal it, imagine this as the basically infinite possible passwords you could have used. And then lets see what happens to that set when we use the wrong techniques to make us more secure.
Requirement: Password Must Use a Combination of Upper and Lowercase Letters, a Number, and at Least One Symbol
We obviously see this one all the time, and here’s what NIST has to say:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets
Interesting. So why do they say that?
Firstly, adding complexity to a password does not necessarily make it more difficult to guess. The only thing that makes a password more difficult to guess using modern brute-force techniques is length. The longer the password the better, complexity barely matters.
Secondly, most users do exactly the same thing when forced to use complexity: The first letter of the password is capitalised, the A becomes @, E’s become 3’s, a number is added to the end, and to be super secure we finish with an exclamation point!
We know people do this, because there are 10’s of millions of leaked password to prove it. “P@ssword1” meets those complexity requirements, and it appears in the Have I Been Pwned stolen password list more than 5000 times. Brute-force password software will crack it in seconds. On the other hand a password like “Alas poor Yorrick, I knew him well” will not pass, but despite being a quite well known (and inaccurate) quote it would take centuries to crack with enormous computing power and the best software available.
This requirement is often made even worse by the arbitrary inclusion or exclusion of specific characters, which just makes it more frustrating for users trying to create passwords. (Note I have had to do this myself in applications where there are some limitations in upstream or downstream services, so I have a little sympathy).
Not convinced? Think about this — if your password database is stolen and the bad guys start brute forcing the password hashes (again see the previous article if you are not sure what that means), which set of possible passwords would you prefer they had to work with:
Requirement: Password Must be Between 8 and 20 Characters
Or some other arbitrary number of characters. The minimum makes sense, but here’s what NIST says about length:
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length
The short maximum length is an odd one, and a bit of a red-flag, but it’s also quite common. It’s a red-flag because it creates some concern about how passwords are being stored. Password should always be stored in a hashed format, and hashes are always the same length (again, see the previous article if you want the detail). It doesn’t matter if the password is 8 characters or 256, the hash is always the same length. This requirement can indicate that there’s some insecure handling of the password at some point, and likely indicates there’s some old technology in the chain somewhere.
And what does that do to our Venn diagram if we know all passwords will be between 8 and 20 characters:
That’s looking much more manageable to crack, but we can narrow it down further…
Requirement: Password Cannot be Pasted Into the Password Box
Some web sites do this on the logon screen, and many do it in the password creation or reset screen. It’s also an issue in many mobile apps. The end result is password managers are also blocked from entering passwords.
I’m not exactly sure why this is done, but some theories suggest it’s to prevent scripted attacks on the site, or to stop malware from stealing your password on your PC. Neither makes a lot of sense — scripted attacks should be prevented by restricting the amount of login attempts, and if malware can steal data from your clipboard, it can most likely steal it from the keyboard as well.
Here’s what NIST has to say:
Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
So now we’re in real trouble, and the hackers have a much smaller set to start with:
Requirement: Password Expires in 90 Days
This one isn’t often seen on the internet, but is a staple of corporate networks and applications the world over. It would be unusual to find a corporate network that doesn’t include some sort of password expiry, but here’s what NIST has to say:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
This is another interesting one, and why is it so? Firstly, it does not make passwords any more secure.
Hands up who can tell me how long they have been in a job by the number on the end of your password? Password expiry every 90 days, password ends in a 8, oh I’ve been in the job for 8 x 90 days or about 2 years already.
Secondly, leaked and cracked passwords will be quickly exploited, so regularly changing them simply doesn’t help.
What’s worse is when they are paired with complexity requirements and a need to manually type them in every time, as is the case for the corporate Windows login. It just encourages users to come up with easy to remember (easy to guess) passwords, or worse, write them down.
And all of a sudden we are here, with a much smaller set of likely combinations — including lots of pet and children’s names with the standard substitution of symbols for A, E and S:
We’ve gone from basically an infinite set to more like a six figure number.
That’s a bit of a simplification and not all the these requirements are stacked on top of each other in every case, but you get the idea.
So What Does Work?
So we now know what not to do. Fortunately NIST has some recommendations on how to encourage users to create and manage secure password as well.
Check for Password Strength (not Complexity)
Web sites and services should be encouraging people to use good passwords with strength tests and checking the password is not on common hacked password lists. Notice I said “strength” testing, not “complexity” testing, there is a difference.
Strength testing looks at the length, use of common phrases or words, repeating characters and common strings, and a number of other factors to determine how long it would take to crack a hashed version of the password. Sounds complicated but it’s not — because the kind people at Dropbox created and shared a tool that does it brilliantly. The tool is called “zxcvbn” and it is simple to embed in a web site and use to test the strength of user password as they are created. More on this one later.
From NIST:
Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter
Check if the Password is Listed in Password Dictionaries or Exploit Lists
Another simple check is to compare the password with lists of passwords used by hackers to brute-force stolen password hash lists. The zxcvbn tool does this using the most common password lists, and it can be extended with custom lists if required.
Another simple way to do it is to use the free API’s at Have I Been Pwned (HIBP). The site collects the data from stolen username/password lists and makes them available in ways that can help us all stay more secure. If you haven’t heard of the site yet, go right now and check it out, and enter your email in to see how many times your passwords have already been stolen.
While anyone can use the web interface to check their own details, HIBP also offer an API that can be used by other sites to check if passwords are already on the lists hackers use every day in attacks.
NIST thinks this one is quite important — for US Govt services it is mandated:
…verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.
What do the Big Websites Do?
Well unfortunately most of them are busy helping us to be less secure.
An interesting 2022 study from the Computer Science department at Princeton found that just 15 out of the 120 most popular English language sites conformed to all of the recommended best practices.
Key findings from the study:
- More than half of the sites did not check passwords against exploit or dictionary lists at all — and allowed all of the 40 most common passwords to be used.
- Only 23 of the sites used password strength meters, but 10 of them were actually misusing them by basing them on complexity only. Just 13 of 120 had useful password strength meters.
- Almost half of the sites still use unhelpful complexity requirements.
Some of the worst performers included Amazon, Netflix and TikTok.
What Should Web Sites Do?
Many of the big players are moving now to password-less options like magic links and passkey which is certainly a step in the right direction, but the migration will be slow and most sites will continue to use passwords for some time (links are provided below to more information).
In the meantime it’s not very difficult for web sites to implement the NIST recommendations and make our lives a little easier and more secure.
To prove it I have created a demo you can view here. For the technical audience there’s a link to the source code below.
The demo allows you to enter a password and test it using the guidelines above. It will check the HIBP database, check the strength using the zxcvbn algorithm, and just for a laugh also check against the common complexity requirements we are typically subjected to.
Go ahead and enter P@ssw0rd1 and watch it pass the complexity test while dismally failing the important tests.
What About the Corporate Networks?
Unfortunately it’s not possible to check password strength on Windows corporate networks, but that doesn’t mean they have to be insecure.
For a start, NIST recommendations like dropping regular changes and pointless complexity requirements are very simple to implement. The maximum length of a password you can type into the Windows login screen is 127 characters — so simply make the minimum a bit longer than the usual 8 or 10 characters and encourage users to come up with phrases instead of words.
There are also a number of tools and methods that can be used to audit Windows domain password lists for simple to guess passwords. If you happen to be a Domain Admin you should go ahead and try it — you will be surprised how easily guessable many of your users passwords are despite your complexity settings and expiration policies.
With a little more work corporate networks can implement Windows Hello authentication, which replaces centralised passwords with biometric login or more secure locally stored PINs (I’m not a huge fan of biometrics but that’s a topic for another day).
And What Can We Do as Users?
While we are stuck with passwords and some of these unhelpful policies there are a few key things you can do to make yourself safer:
- Make your passwords longer where ever possible
- Use a password manager where ever possible
- Never re-use passwords across sites
- Share this article with your local web developer or sysadmin to spread the word :)
- Oh and a slightly different topic and pet peeve — if a site forces you to enter a password hint enter some nonsense only you will remember. Example: “What’s your mothers maiden name?” Answer: “Palpatine-Skywalker”
Hope that helps you all, please leave a comment if you have any questions or suggestions.
About the Author
Mark is a 20+yr IT industry veteran, with technical expertise and entrepreneurial experience in a range of fields. For many years now his passion has been building on AWS, and he holds certifications including Solution Architect Professional and the Advanced Networking Specialty. He wants you to know that he is an infrastructure and architecture expert who writes code, not a professional software developer — just in case you spot something odd.
Mark has spent the last few years in the banking industry, were he is currently building and leading a team focused on using AWS serverless technologies to reduce costs and speed up the time to market for new services and products.
You can also find Mark on:
GitHub — https://github.com/markilott
LinkedIn — https://www.linkedin.com/in/markilott/
