Passwords were supposed to fix authentication. Instead, they have become a source of significant problems. Users continue to choose weak or simple-to-guess  passwords and reuse the same passwords on multiple services. They also tend to question restrictions: “Which of these rules are reasonable? Which are most effective? Why do we have all these requirements?”

Password policies continue to evolve even if user attitudes have not. Experts suggest placing more emphasis on checking passwords against known weak password lists and focusing less on password expiration policies. Here are the current best practices in use:

• Set complexity requirements, such as meeting a character minimum, and use certain character types (mixed case, numerals, and special characters).
• Prevent users from choosing previously used passwords.
• Require passwords to be changed periodically and perhaps frequently.
• Check passwords against lists of most-common or especially weak passwords.

Password standards

The National Institute of Standards and Technology (NIST) addressed the question of password policies by issuing NIST Special Publication 800-63B (Digital Identity Guidelines – Authentication and Lifecycle Management). Section 5.1.1 “Memorized Secrets” has much to say about passwords and how they should be managed and stored. The requirements are actually pretty lenient: User-supplied passwords must be at least eight alphanumeric characters; passwords randomly generated by systems must be at least six characters and may be entirely numeric.

NIST has been updating its standards and the most significant new requirement: The system must check prospective passwords against “a list that contains values known to be commonly used, expected, or compromised.” Types of passwords that might be disallowed based on such checks include:

• Passwords obtained from previous breaches
• Dictionary words
• Repetitive or sequential characters (e.g., aaaaaa or 1234abcd)
• Context-specific words, such as the name of the service, the username, and derivatives thereof

To confuse the issue, NIST’s recommendations are not specifically required; there is no organization whose role is to enforce these policies, and NIST’s guidelines explicitly recommend against complexity requirements.

The rest of the NIST recommendations are smart measures based on common sense and real-world experience. For example:

• The system should allow paste functionality on password entry, to facilitate the use of password managers.
• Passwords should not be stored; the system should store a salted hash—the addition of random data in a one-way password hash—of the password.
• The key derivation function to generate the salted hash should include a “cost factor”—something that takes time to attack, reducing the chances of a successful brute force attack.
• Finally, as I’ve long argued for, the system should permit the user to display the password as it is being entered, rather than just asterisks or dots. Usually this option is invoked by clicking an eyeball icon.

Windows password policies

Because the Windows domain password is the main password for users in so many enterprises, the default Windows policies are, at least, the starting point for most organizations. For many, there is no obvious reason to go any further than the defaults.

The Windows default settings are not necessarily the same as those in the Windows Security Baselines, which are groups of policy settings “based on feedback from Microsoft security engineering teams, product groups, partners, and customers.” The baselines are included in the Microsoft Security Compliance Toolkit, which also includes policy-related tools for administrators. The Security Baselines serve as another very common setting, by virtue of being a Microsoft-endorsed configuration.

The most interesting settings, at least recently, are the minimum and maximum password age. The minimum age is the number of days before users are allowed to change a password. The maximum is the number of days after which users must change their password. The default minimum is one day, both for Windows and the security baselines; the maximum defaults to 42 days for Windows and, until recently, 60 days in the security baselines. These settings are enabled in almost all default configurations.

The default levels are changing

But in May 2019, Microsoft announced changes in the Security Baselines for Windows 10 and Windows Server build 1903: The minimum and maximum password ages will no longer be set in the baselines and therefore will not be enforced.

Microsoft cites research (see “An Administrator’s Guide to Internet Password Research” and “The Security of Modern Password Expiration“) to claim that password expiration policies are no longer considered to have great value. Other measures, such as checking lists of banned passwords, are more effective. As they note, Windows Group Policies don’t provide for checking such lists, so neither can the Security Baselines, which is a good example of why you should not rely only on the baselines. Microsoft offers some of the more advanced capabilities in Azure AD Password Protection.

Password complexity: The ground rules

What is the default Windows password complexity policy?

• The password may not contain the account name or variations on the account name.
• It must contain characters from three of the following five groups (quoted from the Microsoft document):
  • Uppercase letters of European languages (A through Z, with diacritical marks, Greek and Cyrillic characters)
  • Lowercase letters of European languages (A through Z, sharp S, with diacritical marks, Greek and Cyrillic characters)
  • Base 10 digits (0 through 9); non-alphanumeric characters (special characters): (~!@#$%^&*_-+=`|\(){}[]:;”‘<>,.?/)
  • Currency symbols such as the euro or British pound are not counted as special characters for this policy setting.
  • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

Everyone who has had to deal with these policies, which are enabled in the Security Baselines, knows what a pain they can be. As the Microsoft document says, enabling the policies “may cause some additional help desk calls for locked-out accounts because users might not be used to having passwords that contain characters other than those found in the alphabet. However, this policy setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve.”

The default password length requirement is seven characters, but elsewhere Microsoft recommends eight characters, as do the NIST requirements. In the Security Baselines, the minimum password length is 14 characters.

The NIST policies specifically reject (though they do not ban) complexity requirements. Microsoft has not removed the default imposition of these requirements from Windows or the Security Baselines, but it may be a change you want to make yourself.

If you want finer control of password filtering but want to stick with Active Directory, you can replace Microsoft’s standard Passfilt.dll with a commercial one or write one yourself, as Yelp did, based on an open source implementation. Examples of commercial replacements are those from nFront Security, ManageEngine, and Anixis. Using one of these replacements, you can implement current best practices within your otherwise standard Active Directory infrastructure.

SecLists keeps a collection of many large common password lists.

Beyond banned passwords

Banned password lists are useful, but another way may be better. Have I Been Pwned is a site that keeps records of major user ID and password breaches and allows you to check whether any of your logins have been compromised.

The site was built and is maintained by Troy Hunt, a Microsoft regional director and well-known security expert. It has data on 369 breached sites and 7,860,402,548 breached accounts. The site also has an API that allows you to check whether a particular account has been breached or just if a particular password exists in the breach database.

Hunt thinks that, once a list is as large as his, it is “exceptionally unlikely to have anything outside that collection which is both terrible and actively used.” The answer is to check against the separate Pwned Passwords database, which contains 551 million passwords that have been in one or more of the breaches, using its API. Hunt says he would set a minimum of six characters and then block anything that shows up in Pwned Passwords. One more tip from Hunt: “I’d block every variation of the company name; nobody on the Acme Corp. website can use AcmeCorp, AcmeCorp1, AcmeC0rp, etc.”

If you want to use the Pwned Passwords API, you can build on one of the many projects already doing so. Typically, they create an environment-native interface to the API, such as with the many PHP libraries, Python and Perl scripts, WordPress plugins, and Java clients, as well as an IFTTT recipe.

In addition to many weak passwords, Pwned Passwords has a large number of passwords that would satisfy any set of complexity rules, so it might seem to be overkill. But compared with the range of possible passwords, 551 million isn’t as big a number as it seems. Nearly all of my own passwords are randomly generated by my password manager, but I tested several passwords I made up on my own in recent years, and none appear in the Pwned Passwords database. So maybe relying on Hunt’s API and a minimum length and blocking organization name variants is the easiest route to strong protection.

I wrote a program to check the contents of one of the SecLists lists of “common credentials” against the Pwned Passwords database. All but 3,663 of 262,000 passwords tested were in Pwned Passwords, and more than half of those that weren’t had fewer than eight characters. Perhaps this means that Hunt is right that checking banned password lists is largely redundant, though if you’re going to check one or the other, it’s easy enough to check both.

But all of this is about usernames and passwords, a technology that we should all hope will someday be deprecated. At the same time you make sure your passwords are strong, move forward with multifactor authentication and biometrics that bypass the inherent problems with passwords.

Password policy best practices: Lessons for leaders

• Stay up to date with recommendations for creating and maintaining secure passwords.
• Minimize opportunities for user password failures.
• Make use of public databases of password failures and account breaches.