
Guidelines for Password Procedures: Here’s What You Should Know
Password policy recommendations: Here’s what you need to know
Password complexity, use of a combination of characters, and regular updates have all long been recommended, however recent recommendations have prompted shifts in policy.
There was supposed to be a solution to the authentication problem in the form of passwords. On the contrary, they have developed into a major source of difficulty. Users repeatedly pick weak or easily guessed passwords and reuse those credentials across various services. Moreover, they are prone to challenge boundaries: “How many of these regulations seem acceptable to you? To what extent do they succeed? For what reason do we need so many rules?”
Even if user views haven’t changed, password policies always seem to be progressing. The experts advise putting less emphasis on password expiration regulations and more on testing passwords against known weak password lists. The present gold standard is exemplified below:
- Define constraints, such as a minimum number of characters and the use of specific character sets (mixed case, numerals, and special characters).
- Users shouldn’t be able to re-use passwords they’ve already used.
- Passwords should be updated at regular intervals, if not more regularly.
- Look them up on a database of known weak or often used passwords.
Password standards
The issue of password policies was tackled by NIST, which published NIST Special Publication 800-63B. (Digital Identity Guidelines – Authentication and Lifecycle Management). Passwords and their proper management and storage are discussed at length in Section 5.1.1 “Memorized Secrets.” In reality, the prerequisites are not particularly stringent: Passwords submitted by users must be at least eight characters long and use a combination of letters and numbers, whereas system-generated passwords must be at least six characters long and can be made up completely of numbers.
The National Institute of Requirements and Technology (NIST) has updated its standards, the most notable of which is the requirement that the system must check potential passwords against “a list that comprises values known to be regularly used, predicted, or compromised.” Some passwords that wouldn’t pass such a test would be ones like:
- Passwords obtained from previous breaches
- Dictionary words
- Repetitive or sequential characters (e.g., aaaaaa or 1234abcd)
- Terms that only make sense in a particular setting, like the name of the service, the login, and variations on those phrases
Confounding matters further, NIST’s recommendations are not mandated; no agency is charged with enforcing these standards, and NIST’s guidelines recommend explicitly against complexity requirements.
The rest of NIST’s advice is sensible precautions based on experience and common sense. Just to give one illustration:
- In order to make use of password managers, the system must provide a paste option when entering passwords.
- Instead of storing the actual password, the system should save a salted hash of it (where random data is added to the one-way hash).
- To make it harder for brute-force attacks to succeed, the key derivation method used to create the salted hash should incorporate a “cost factor” that takes time to assault.
- Last but not least, I have long advocated having the option to see the actual password as it is being input, rather than just asterisks or dots, while using the system. The typical method of activating this feature involves selecting the eye icon.
Windows password policies
Many businesses rely on the Windows domain password as their primary password, so these predefined Windows policies serve as a baseline. Many people just stick with the settings because there doesn’t seem to be a better option.
The Windows Security Baselines are a set of recommended policies that were developed “based on feedback from Microsoft security engineering teams, product groups, partners, and consumers,” however they may differ from the default settings in Windows. The baselines are part of Microsoft’s Security Compliance Toolkit, which also contains tools for administrators linked to policy. In addition to being a Microsoft-recommended setting, “Security Baselines” enjoy widespread usage.
The minimum and maximum password ages are the most intriguing options, at least as of late. The minimum age is the number of days that have passed since a password was last changed. Passwords can only be used for so long before they need to be changed. Both Windows and the security baselines have a default minimum of one day, and both have default maximums of 42 days for Windows and, up until very recently, 60 days for the security baselines. These options are often enabled by default.
The default levels are changing
In May 2019, however, Microsoft announced updates to the Security Baselines for Windows 10 and Windows Server 1903: When the baselines are updated, the minimum and maximum password ages will no longer be enforced.
According to studies cited by Microsoft (including “An Administrator’s Guide to Internet Password Research” and “The Security of Modern Password Expiration”), password expiration rules are no longer valued. More efficient methods exist, such as using password blacklists. You shouldn’t rely just on the baselines because, as they point out, neither Windows Group Policies nor the Security Baselines offer support for validating such lists. Microsoft’s Azure Active Directory Password Protection has some of the most sophisticated features available.
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.
This policy, which is enabled in the Security Baselines, is a nuisance for everyone who needs to deal with it. According to the Microsoft white paper, activating the policy “since some users aren’t accustomed to having passwords that contain characters other than those found in the alphabet, this change may result in an increase in locked-out accounts resulting in calls to the help desk. Nevertheless, the default policy is lenient enough that everyone may comply with the rules after a short period of adjustment.”
Seven characters is the minimum length for a password, however Microsoft and the NIST both prefer eight. According to the Security Baselines, a passphrase ought to be at least 14 characters long.
NIST guidelines discourage, but do not outright forbid, the use of complexity requirements. Windows and the Security Baselines still enforce these standards by default, and Microsoft has no plans to modify this.
If you’re set on using Active Directory but would like more granular control over password filtering, you may either purchase a commercial replacement for Microsoft’s standard Passfilt.dll or create your own, like Yelp did, using an open source implementation as a starting point. Products from nFront Security, ManageEngine, and Anixis are only few examples of available commercial alternatives. By switching to one of these alternatives, you can incorporate state-of-the-art procedures into a conventional Active Directory setting.
SecLists stores a trove of huge, frequently-used password lists.
Beyond banned passwords
While lists of prohibited passwords are helpful, there may be a better solution. If you want to see if any of your online accounts have been stolen, you can utilise the website Have I Been Pwned, which keeps track of large breaches involving user IDs and passwords.
Troy Hunt, a Microsoft regional director and a renowned security specialist, created and maintains the site. There is information on 369 compromised websites and 7,860,402,548 compromised user accounts. You can use the site’s application programming interface (API) to see if a given username or password has been compromised.
It is “exceptionally unlikely to have anything outside that collection which is both bad and actively used,” in Hunt’s opinion, once a list has grown to the size of his. The solution is to use the Pwned Passwords API to verify against its own database of 551 million passwords that have been compromised in one or more of the incidents. According to Hunt, he would require a minimum of six characters and then blacklist any passwords that are listed in the database Pwned Passwords. And here’s one more piece of advice from Hunt: “I’d block every variation of the corporate name; nobody on the Acme Corp. website can use AcmeCorp, AcmeCorp1, AcmeC0rp, etc.”
Many existing apps make use of the Pwned Passwords API, so if you wish to do the same, you can simply expand upon those. An IFTTT recipe, a PHP library, a Python script, a Perl script, a WordPress plugin, a Java client, and so on are all examples of environment-specific interfaces to the API.
Pwned Passwords has a big number of passwords that would satisfy any set of complexity standards, therefore it may seem like overkill to include so many weak passwords as well. However, 551 million isn’t as large a figure as it looks when contrasted to the variety of possible passwords. Most of my passwords are generated randomly by my password manager, but I’ve tested a few that I’ve come up with on my own in recent years and they don’t show up in the Pwned Passwords database. It’s possible that the simplest way to ensure robust security is to rely on Hunt’s API, set a mandatory minimum length for company names, and then prohibit any versions of those names.
One of the SecLists lists of “common credentials” was the basis for a programme I created to query the Pwned Passwords database for compromised passwords. More than half of the non-Pwned Passwords passwords were fewer than eight characters, and 262,000 passwords were examined. Possibly this means that Hunt is correct in his assessment that checking prohibited password lists is essentially unnecessary; but, if you’re going to check one or the other, you might as well check both.
However, this is all about user IDs and passwords, a system we can all hope to see phased out in the future. In addition to using robust passwords, you should use additional methods of authentication like multifactor authentication and biometrics that avoid the weaknesses that passwords have by design.
Password policy best practices: Lessons for leaders
- Keep abreast with the latest advice for making and using strong passwords.
- Reduce the likelihood of password failures by users.
- Use archives of compromised usernames and passwords that are available to the public.