Humans aren’t great with passwords – specifically, in creating strong, random, unique passwords and keeping them private. This leads to issues ranging from account takeovers (when an attacker takes control of a victim’s account by obtaining their password), to financial scams and identity theft (when goods or services are bought or sold using a stolen identity), to data breaches and other security incidents.
The truth is that we suck at passwords because passwords are in many ways, flawed. While being deceptively simple – quite literally a string of characters you should keep secret to prove one’s identity – the reality is a lot more complicated than that. Naturally, counteracting this problem involves educating users about why their passwords are terrible, using password managers and of course enforcing two-factor authentication (2FA) wherever possible. However, there’s one other important aspect to consider when improving password security within your organization, and that is making sure you have a successful password policy.
What is a password policy?
A password policy is a set of rules usually (but not always – we’ll get to that in a bit) enforced by a system administrator, to steer users in the direction of choosing strong passwords. Password policies may sometimes be part of a larger information security or cyber security policy within an organization.
When implemented correctly, a password policy should direct users into choosing passwords that conform to a set of rules that make them more secure. The trouble is that creating these rules are usually a shot in the dark and do not necessarily result in stronger passwords, in fact, many times, a bad password policy might actually be hurting your security policy.
The NIST Special Publication 800-63B
In 2003 the US Department of Commerce’s National Institute of Standards and Technology (NIST) put together a number of recommendations in 2003 in the NIST Special Publication 800-63B, Appendix A as part of their Electronic Authentication Guideline publication. Fourteen years later in 2017, after the original author regretting some of the advice, given in the 2003 publication, NIST overhauled these recommendations to bring them more in line with developments in password security, research and the benefits of hindsight.
While they may have made sense then, the recommendations laid out in the 2003 NIST 800-63 publication unfortunately still form part of the conventional wisdom of many system administrators and regulatory frameworks when it comes to implementing password policies. The 2003 NIST SP 800-63B ended up popularizing passwords that are difficult for attackers to bruteforce (an attack in which an attacker submits many passwords with the hope of eventually guessing correctly), but crucially, also difficult for people to remember. Back in 2003 recommending users pick an eight-or-more character password which includes numbers and symbols, may have been seen like sage advice – it would have meant that many people would have gone from comedy passwords like password123 to P@ssw0rd123, which, in theory is a more secure password – except, no, not really.
There is a phenomenon in economics known as the tragedy of the commons. The concept states that what seems like a good idea for an individual isn’t so if carried out by everyone else. If one person had to choose P@ssw0rd123 as their password, that’s fine, however, the moment everyone else starts following the same patterns and picking the same password, or indeed the same password pattern, that makes a once expensive attack significantly easier – an attacker can now leverage predictability, probability and increasingly faster hardware to crack passwords quicker than ever before. To illustrate this, as of the time of writing of this article, P@ssw0rd123 appears 1,256 times in data breaches tracked by Have I Been Pwned.
What makes a good password policy?
NIST’s overhauled 2017 version of the SP 800-63B, is recognized as an up-to-date and sensible set of guidelines to follow when designing a modern-day password policy. NIST isn’t the only governmental entity to provide a wealth of sound, authoritative information about authentication guidelines – the UK’s National Cyber Security Centre (NCSC)’s Password administration for system owners guidelines are another excellent resource, as is Microsoft’s Password Guidance paper by their Identity Protection Team.
The following recommendations are drawn primarily from the sources listed above. Naturally, the resources mentioned above go into an awful lot more detail than is covered in this article, and are a recommended reference in addition to what is distilled here.
It’s important to keep in mind that there is no magic number of requirements that makes a password “unhackable” – to reiterate the NCSC’s mantra – passwords can only do so much.
"Passwords have a limited ability to protect your data and systems. Even when implemented correctly, passwords are limited in helping prevent unauthorised access. If an attacker discovers or guesses the password, they are able to impersonate a user. Less obviously, every new password has an associated burden on the person using it.” — NCSC Password administration for system owners
With this being said, there are a number of achievable password policy guidelines which can lessen the burden on users while ensuring they choose stronger passwords.
The longer, the better (usually)
Password length is one of the primary factors which determines a password’s strength in resistance to attacks. While there are exceptions to the rule, the longer a password is, the harder it is for an attacker to crack – short passwords are easy for attackers to bruteforce and most password dictionaries (lists of commonly used passwords) already contain thousands of combinations for short passwords.
For this reason, setting a minimum password length in a password policy is key. NIST recommends a minimum of 8 characters.
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber.
At the same time, users should be encouraged to make their passwords as lengthy as they want – there is no reason to forbid the use of lengthy passwords. Preventing users from choosing long passwords, aside from being bad for usability, means they will have a rougher time choosing passphrases and using password managers. Of course, setting a reasonable upper limit to password length to avoid other technical problems – here is NIST’s recommendation.
Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length
While it’s more than reasonable to allow up to a maximum of 64 character passwords, some password managers allow users to generate even longer passwords – as a result, if you’re in control of password length, setting a password length’s upper limit to somewhere around 256 characters is more than enough and improves usability.
Having said this, one must keep in mind that requiring excessively long passwords (that is, setting the minimum number of characters very high), could have adverse consequences. A study conducted by Microsoft found that users may end-up choosing repeated patterns that meet character length requirements but are not hard to guess.
Excessive length requirements (greater than about 10 characters) can result in user behavior that is predictable and undesirable.
As a result, it’s recommended to set minimum password character requirements in the region of 8 to 10 characters.
Do not require special characters
Password complexity rules have time and time again been proven to be the achilles heel of user-chosen passwords. Password composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords, however, research has shown, that not only is this not effective, but it may make the situation worse because users tend to respond predictably to these imposed requirements.
In addition, highly complex memorized passwords simply make it harder for users to memorize, thus increasing the chances that they will write their passwords in a passwords.docx file on their desktop, or attach it to a sticky note on their desk.
Similarly, some websites or systems prohibit users from using certain characters. This is typically a result of fundamentally misguided approaches to prevent attacks such as Cross-site scripting (XSS) or SQL injection (SQLi).
NIST is very clear in this regard – allow users to pick what characters they want.
All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.
Additionally, NIST’s guidelines also make it clear that password policies should not force users to use prescribed password complexity rules.
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets
This does away with the antiquated wisdom of forcing users to stuff as many special characters in their passwords, making them hard to memorize, difficult to type and prone to error and frustration. This is also corroborated by Microsoft’s guidance.
Eliminate character-composition requirements
Microsoft goes on to suggest that this causes most users to end up picking similar patterns, once again, fulfilling the tragedy of the commons phenomenon discussed earlier.
Most people use similar patterns (i.e. capital letter in the first position, a symbol in the last, and a number in the last 2). Cyber criminals know this, so they run their dictionary attacks using the common substitutions, such as “$” for “s”, “@” for “a,” “1” for “l” and so on.
In summary, requiring special characters in passwords is something the industry unfortunately got wrong. Try not to make it mandatory in your password policy, let users choose if and how they want to make use of special characters.
Password hints are a bad idea
While thankfully, password hints aren’t nearly as popular as they used to be, they’re exactly what an attacker needs to get a head start when trying to gain access to a victim’s account.
Once again, NIST’s guidelines make this amply clear that they think this is a bad idea.
Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.
Avoid routine password expiry
Alongside password complexity, imposing a password’s expiry is one of the most common anti-patterns in password policies. It doesn’t require much research to realize that people will just pick patterns to cope with the requirement, for example adding an incremental number or adding the name of the month at the end.
The rationale behind the approach of rotating passwords regularly is that should the password be compromised, by forcing a routine change, that password is no longer valid, therefore the attacker who stole it can not use it successfully. Say your organization rotates passwords quarterly, an attacker still has (at best) three months to successfully use that password.
Since attackers do not exactly sit on passwords for three months before exploiting relevant accounts, the whole practice of expiring passwords is flawed. Microsoft argues that requiring users to periodically change passwords not only carries no real benefits, but is actually harmful.
Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password). Password change offers no containment benefits cyber criminals almost always use credentials as soon as they compromise them.
Of course, this does not mean that you should never expire users’ passwords – if for example users are subject to a data breach or have been the victim of a phishing attack, you certainly want to use password rotation as a mechanism to limit potential damage. In every case, it’s highly recommended to keep the user in the loop of what’s happening and clearly communicate the reason why their passwords need to change in plain language.
Prohibit the use of breached passwords
While the above recommendations emphasise user friendliness when it comes to choosing a password, users will still inevitably pick weak passwords. Technically, the password password or 12345678, which would take an attacker less than a second to crack, are valid passwords as prescribed by the above rules – they are 8 characters long and have no complexity requirements.
To such an extent, a successful password policy should not allow users to pick passwords that are bound to getting compromised in a few seconds. Breached passwords are arguably the biggest source of passwords attackers have available to them.
Once a password is in a data breach, it should be considered unsafe to use, and should never be used again. Once a password has been dumped on the Internet, there are all sorts of malicious people who would have gained access to it, and as a result, it makes it significantly risky to use the password. NIST makes the following recommendation.
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: Passwords obtained from previous breach corpuses.
This essentially means that when someone creates a new password or changes an existing one, you should ideally compare it to passwords in data breach corpuses to check if it’s been compromised already. NIST also recommends prohibiting the use of dictionary words and context-specific words, this means that whole words found in a dictionary should be prohibited (e.g. the words anywhere, hospital and keyboard are all 8 character words, however, they should be prohibited because they would be trivial for attackers to guess), as well as words which are may be popular in your organization (e.g. company name, product names and logo colors) should all be prohibited from being used in users’ passwords.
Naturally implementing and enforcing this will very much depend on the system at hand. Check out Have I Been Pwnd’s API use cases to find an implementation that is appropriate for your use case (e.g. implementing this in Microsoft Active Directory).
Implement an account lockout or throttling policy
Account lockout policies are simple but incredibly effective tools which any successful password policy should implement. An account lockout policy sets a time period an account should be locked out after a number of failed password attempts. Locked accounts are automatically unlocked after the account lockout duration.
Account lockout policies help significantly slow down online password attacks. NIST suggests setting a rate-limit of no more than 100 failed authentication attempts, after which the user must wait between 30 minutes, up to 1 hour to try again.
Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100
In practice, depending on the system you are defending, you may want to make this number significantly lower than 100 – the NCSC recommends allowing only between 5 to 10 consecutive failed login attempts before locking the account for a short period of time, and progressively increasing that time upon every subsequent authentication failure – this technique is known as ‘throttling’. The major advantage of this technique is that it restricts the number of guesses an attacker can make while giving users multiple opportunities to enter their password correctly.
Encourage password managers and require 2FA
While they may initially add some friction to the user experience for some users, the use of password managers and two-factor authentication (2FA) drastically improve the security of users’ online accounts.
Password managers allow users to pick more random, less predictable passwords and makes it easy for users to use a different password for each account, whilst 2FA makes it harder for an attacker to gain access to users’ accounts, even if they know their password (e.g. stolen as part of a data breach or a successful phishing attempt).
While all this information is useful, rolling out a successful password policy should also come with user education and awareness. Since users are the ones who will be using the password policy on a day-to-day basis, it’s important for users to be kept in the loop
Naturally, how you choose to communicate changes to policies will vary from one organization to another. Whatever the organization, it is essential to let users know a policy is going to change, and secondly, it is important to explain to users why a new password policy is going to be put in place and what they can do to create long, random and unique passwords.