Password Policies that Actually Work For Users, Part 3 (Tech Tuesdays #14)
Quick recap:
- In Part 1 of this series (Tech Tuesdays #13), I introduced the problem with traditional password policies: They suck and actually worsen security.
- In Part 2 (Psych Fridays #14), I talked about why traditional password policies suck and make things worse: They suck and make things worse because these old policies don’t take into account human psychology.
Don’t worry, the industry is always improving on things. This is normal!
Both Microsoft and the NIST (National Institute of Standards and Technology) have come up with a set of new password policies that take into account human psychology, based on actual user research. My job here is just to distill the most important findings and help you transition to these better policies.
New Rule #1: No more character-composition rules
From parts 1 and 2 of this series, we’ve already covered that one of the most user-unfriendly and counterproductive policies is forcing users to have character-composition rules in place (forcing them to use a mix of uppercase, lowercase, numbers and special characters).
So, new password rule #1: Stop it. No more of that. They should be able to use whatever characters they want and however they want to.
Obviously, this rule, taken alone, will likely be terrible. That’s why we have other rules in place, so don’t worry. Just read on.
New Rule #2: Accept EVERY character - even emojis
Alright, after making sure you stop forcing users from passwords that MUST have a specific mix of upper/lowercase+numbers+special chars, the next rule is specifically ALLOWING any character. Even emojis!
Think of rule #1 and rule #2 as complementary. It’s not enough that you stop forcing the use of certain characters. You also have to stop banning certain characters in passwords.
Users must be able to use whatever character they want in their passwords - again, even emojis if they want to. You’d be surprised how many banks and financial institutions still fail this rule, banning certain characters (or only allowing a small subset of special characters) for password use.
“But JV, we need to ban some characters, like single quotes and other potential delimiters, to stop SQL injection vulnerabilities in our login page!”
No, you really don’t. If that’s what you are thinking, then you don’t understand one (or both) of these things:
- How to store passwords correctly.
- How SQL Injection works.
If your developers still don’t understand this, you need to hire an expert or consultant.
New Rule #3: Minimum length only, no (reasonable) maximum length.
Ok, so now we know we shouldn’t force the use of any characters, plus we shouldn’t ban the use of any characters. The next step, the next rule, is simple: Only prescribe a minimum length (8 or more), and then don’t have a maximum password length.
The spirit of this rule is two-fold:
- Obviously, we want passwords of a certain minimum length, as the easiest way to filter out obviously weak passwords (anything 7 characters or shorter)
- We also don’t want the user to have a PRACTICAL limit, so if he wants to use his favorite quote as his password, we’ll let him. This means no rules like “passwords should be no more than 15/20/30 characters” or anything like that. It should be large enough so that users are not likely to encounter the limit - say, anything from 64 to 200 characters.
There are two technical considerations here that are worth talking about.
First, from a password storage perspective, all our passwords, whether they are 8 characters or 100 characters, will take up the exact same space in our database. That’s because, if you’re storing passwords correctly, they’ll be stored as a hash (the output of a correctly-tuned key derivation function), meaning every single password will be of the same length, regardless of whatever the original plaintext password was. So “saving on storage” is not a concern, and you can let users choose whatever password length they want.
Second, while there is no extra storage cost for long passwords, we do still want to implement a backend limitation that is unlikely to inconvenience 99.999% of your users (again, maybe 64-200 characters is good). This has nothing to do with password security itself. Rather, this is to protect our backend server from Denial of Service (DoS) attacks. Remember, if you are storing passwords correctly, this means you are using a properly-tuned KDF, which basically boils down to a hashing process that is repeated tens of thousands of times or more per login request. This means if a malicious user can submit an arbitrary-length password (say, copy-pasting the contents of a 10MB text file), then the backend will have to hash that 10MB data tens of thousands of times, which will take a while and peg a CPU core. Do it enough times, and the attacker can easily DoS your server.
This is easily thwarted though. In my application framework, for example, there is a global setting for max_password_length (defaults to 200 characters), and the login module first checks if the submitted password conforms to the max_password_length setting. If it doesn’t (say, the malicious user used browser plugins like TamperData to bypass client-side length restrictions), then the backend server disregards the request without triggering the KDF process.
So, recap: Make a minimal length rule (8 or more), make no practical length limit, but implement a reasonable max to avoid DoS vulnerabilities.
New Rule #4: Check passwords against a list of known bad passwords
The last three rules help make the mental overhead for users lower. Less frustration = less chances users will engage in counterproductive behavior.
This 4th new rule, however, is about having an effective filter for bad passwords: Check desired passwords against a list of known bad passwords.
This means whenever a user signs up or logs in, you should compare the submitted password to a list of known bad passwords. The NIST’s minimum recommendation is that you do this for the top, most common passwords (top 1K / top 10K). You’ll see lots of those lists around the internet.
However, it’s actually feasible to compare against 550 million known bad passwords - these are passwords used by real people, in real applications, that have been exposed through various data breaches. You can download this 550M list through Troy Hunt’s Pwned Passwords site. He also provides API access.
Note that the Pwned Passwords list only contains the SHA-1 hash of the original passwords, not the plaintext ones. This is to avoid weaponization of the list - the defenders can use it easily, but it’s hard for attackers to use it.
In your case (as defenders), all you need to do is SHA-1 hash the submitted password, and compare against the Pwned Passwords list. If there is a hash collision, then whatever the original password was (your system never needs to record or hold on to the submitted plaintext after the SHA-1 hash), it’s in the list so it should be disallowed. Inform the user to make a different one, because that one is already known to attackers (or use the term “hackers” if you really want to scare them).
New Rule #5: Never force password expiration, unless you’ve been breached.
Finally, user passwords that have gone through rules #1-4 should never be expired, ever. Unless you believe you suffered a data breach that exposed passwords, you should not keep inconveniencing users to create new ones. Remember what we learned from Part 2 - this policy of frequent password expiration actually made passwords MORE vulnerable for almost an indefinite amount of time, because users will just eventually default to using counters / incrementors.
Go modernize your password security
That’s about it. These are the essential 5 new rules for a modern password policy that is more effective and human-centric. Get to work and get it done.
I skipped some recommendations that are also important but less technical, particularly “user education”. This basically boils down to teaching users never to reuse passwords, keeping passwords secret, using passphrases instead of single words, never writing them down, etc. However, you should implement the 5 new rules above first. If you don’t modernize your password policies, then your users will never have the opportunity to get educated, as they’ll still struggle with archaic rules that will overburden them.
This has been issue #14 of Tech Tuesdays, my weekly column about common technology-centric issues, or tech topics that interest me in general. If you liked this week's topic, "like" or "share" (or both!) to make sure your friends and colleagues also get to enjoy this.