Password policy recommendations: here's what you need to know

Password policy recommendations: here's what you need to know

Password policy recommendations: here's what you need to know

  • 1 year ago
  • postat de: NSHOST

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

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

Password policies continue to evolve, even if user attitudes haven't. Experts suggest putting more emphasis on checking passwords against lists of known weak passwords and less focus on password expiration policies. Here are the current best practices:

  • Setting complexity requirements, such as meeting a minimum number of characters, and using certain types of characters (mixed uppercase, digits, and special characters).
  • Preventing users from choosing previously used passwords.
  • Requiring passwords to be changed periodically and perhaps even frequently.

Research shows that even an eight-character password—with a healthy mix of numbers, uppercase letters, lowercase letters, and symbols—can be cracked within eight hours by the average hacker. Shorter or less complex combinations can be cracked instantly or within minutes by any hacker who knows what he's doing, even if he uses only basic equipment.

Meanwhile, a password that's 18 characters long—and uses a mix of numbers, lowercase and uppercase letters, and symbols—could take up to 438 trillion years for the average hacker to crack, according to Hive Systems.

 

Password

Standards The National Institute of Standards and Technology (NIST) addressed the issue of password policies by publishing NIST Special Publication 800-63B (Digital Identity Guidelines - Authentication and Lifecycle Management). NIST has updated its standards, and the most important new requirement: the system must check possible passwords against "a list containing values ​​known to be commonly used, expected, or compromised." The types of passwords that might be disallowed based on such checks include:

  • Passwords obtained from previous breaches
  • Common dictionary words
  • Repetitive or sequential characters (for example, aaaaaa or 1234abcd)
  • Context-specific words such as service name, name user and their derivatives

To complicate matters, NIST recommendations are not specifically requested; there is no organization whose role it is to enforce these policies, and the NIST guidelines explicitly advise against imposing complexity requirements.

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

  • The system should allow pasting functionality on password entry to facilitate the use of password managers.
  • Passwords should not be stored unencrypted in databases; the system should store an encryption key that knows how to encrypt and decrypt passwords saved in encrypted format in the database.
  • bcrypt's hashing function allows us to build a password security platform that scales with the system and always hashes passwords with very good efficiency.
  • Finally, as I have long argued, the system should allow the user to display the password as it is entered, rather than just asterisks or dots. This option is usually invoked by clicking on an icon with an eyeball.

 

Windows Password Policies

Because the Windows domain password is the primary password for users in so many enterprises, the default Windows policies are at least the starting point for most organizations. For many of them, there is no obvious reason to go beyond the defaults.

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

The most interesting settings, at least recently, are the minimum and maximum age of passwords. 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 value is one day for both Windows and Security Bases; the maximum is 42 days for Windows and, until recently, 60 days in Security Bases. These settings are enabled in almost all default configurations.

 

Password Complexity: The Basics

What is Windows' default password complexity policy?

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

 

All those that have had a deal with these policies, which are enabled in Security Baselines, I know how painful they can be. As the Microsoft document says, enabling the policies "may cause some additional calls to the help desk for blocked accounts, as users may don't be used to having passwords that contain non-alphabetic characters. However, this policy setting is liberal enough that all users can comply with the requirements with a minor learning curve".

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

 

Beyond Banned Passwords Banned password

lists are useful, but there's a better way. Have I Been Pwned is a site that keeps track of major ID breaches usernames and passwords and allows you to check if your access data has been compromised.

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

If you want to use the Pwned Passwords API, you can rely on one of the many projects that already do so. They typically create a native environment 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.

Pwned Passwords has a large number of passwords that would satisfy any set of complexity rules.

 

Password Policy Best Practices: Lessons for Leaders

  • Stay up-to-date on best practices for creating and maintaining strong passwords.
  • Minimize opportunities for user password failures.
  • Use public databases of password failures and account breaches.