Password policy recommendations: Here's what you need to know.

Complexity, uniqueness, and periodic change have long been the top best practices for passwords, but new recommendations have led to changes around password policies.

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.