— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —
It’s time for our monthly security blog again. Almost a year ago NIST published a new version of their password and digital identity recommendations. What are those recommendations, and why have they changed?
The new recommendations put an end to many of the crappy guidelines that we all hated, like requiring all kinds of special characters in your password, or having to change the password every x weeks. Slowly, people start to understand that these were not very good guidelines as they weren’t very well aligned with human behaviour.
Are you an ambulance driver, and need a password? Try ‘ambulance’. If the system also requires numbers, what about ‘ambulance1’? Special characters? Good chance that you will select ‘ambulance1!’. And next month, when the password needs to be changed, it will be ‘ambulance2!’, and so on. That’s what happens when you try to annoy people with these requirements. It gets ‘less’ secure, instead of ‘more’.
NIST is a federal agency within the US Department of Commerce, and its task is “To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.” That’s a mouthful, but it just means they create guidelines, and in practice many of those guidelines become industry standards. So, although they are not an independent organisation, the fact that they created these guidelines is a big deal.
Here’s what we think is important, and more developers should pay attention to.
Highlights
Don’t require complex passwords
The most important change is that according to NIST, websites should no longer require complex passwords. This refers to those rules that tell you your passwords needs to have letters and numbers, a minimum length, and at least characters from 3 out of 5 special categories, without using control characters, but including unicode characters that are categorized as alphabetic character (but are not uppercase or lowercase), including characters from Asian languages.
Euhh… Right! The new rules for ‘memorized secrets’ are:
- There is a minimum length of 8 characters (or 6 if the password was generated by the server).
- The password needs to be checked against a list of commonly used or compromised passwords.
Regarding ‘strength’, those are the only requirements and they make a lot more sense. It’s good to know however that there is some discussion on whether the minimum length shouldn’t be a lot higher. E.g. see here and here.
Furthermore, it should be ‘possible’ to have passwords of at least up to 64 characters in length, but it’s just optional to the user to actually make them that long. Also, it should be allowed for passwords to contain any of the printable ASCII characters (including space) and also unicode characters. See https://pages.nist.gov/800-63-3/sp800-63b.html#-511-memorized-secrets
Do detect fraudulent patterns
Because these rules might result in easier to guess passwords, websites are strongly adviced to build rate-limiting mechanisms. Actually, we should no longer ask from our users to come up with unguessable and unbreakable passwords, but put more effort in recognizing when a hacker tries to break in. This makes a lot more sense if you think about it. Compare this with credit card companies trying to detect fraud. There’s a relatively simple numeric code, but they often use tens of different parameters to detect fraud. They combine the time, the amount, the geographical location, the account numbers and many other variables to detect fraudulent patterns. A purchase in a different country from your home country is weird, but okay. If it happens an hour after you used your creditcard at home, it’s probably not okay.
Software companies should take the same approach: Become better at detecting fraudulent patterns. Don’t foolhardily try to get the user to come up with strong passwords all the time. Time has proven that most users are pretty bad at that. In the future companies could use more and more AI solutions to detect fraudulent patterns, and not just during the authentication process, but also after that.
Don’t use password hints
Websites should no longer allow the user to store password hints which are accessible to unauthenticated users. The recommendations seem to say that it ‘is still allowed for authenticated users’, but that makes you wonder what the usage is if you’re already authenticated. Perhaps they mean that hints are okay when sent via email, but in that case password resets are just as easy. We would suggest to completely get rid of all password hints.
Don’t force periodic password changes
This is another big change from previous guidelines. When a user has a password, he should stick with that password. Being forced to update your password every now and then makes the password less secure, because almost everyone will just increment a number or apply some other basic rule to let the password be accepted and still easy to remember. Also, it would give you little extra security, as hackers tend to abuse your credentials shortly after stealing them, not a year later. As explained before, the administrator should be able to recognize suspicious behaviour and block any attacks.
The guidelines do say however, that if there’s evidence that the users’ credentials got compromised, the user should immediately be forced to change his password.
Don’t disable copy-paste for password fields
Some ‘annoying’ websites disable copy-paste functionality for password fields, in a misguided attempt to improve security. However, this measure prevents users from using a proper password manager, and as a result they will fall back to easy-to-guess passwords. The new guidelines practically forbid this annoying practice. Hurray!
Do require reauthenticate
Not new, but still good to know: Depending on the level of confidence needed for the authentication, a user should reauthenticate after 30 minutes of inactivity, or after 12 hours regardless of activity. So, even if there is user activity, the session should be ended after 12 hours. This is to avoid scripts that mimic user activity, thereby creating a potentially eternal keepalive function. Keep in mind that reauthentication can still be implemented in many different ways. E.g. care should be taken in just redirecting to a login page, thereby throwing away everything the user was working on. Instead, show a warning when the session is about to time-out, or ask for reauthentication in a separate window.
Conclusion
So, the next time you’re implementing your own authentication mechanism, keep these requirements in mind.
- No complexity requirements. Just check new passwords against a list of compromised passwords.
- Detect fraudulent patterns. Implement rate-limiters and recognize other weird behavior.
- No password hints. Best if the users have a password manager, and those managers don’t need hints.
- No periodic password changes. Let the user choose a password, and let them stick with it.
- Allow copy-paste in password fields. Because that’s what password managers use.
- Reauthenticate. Periodically, and after being inactive too long.