Anyone who has ever signed up somewhere knows password rules: 8 characters, uppercase letters, lowercase letters, special characters, …. But are these rules really useful and what are good password rules?

To answer this, we should first ask ourselves what the goal of password rules is. Applications have password rules to prevent users from choosing bad passwords. In most cases, the best solution by far would be to use password managers and randomly generated passwords. But since developers have no control over how users manage their passwords, password rules are supposed to guide users in the right direction. But which rules are useful for this and which are not so much?

Less is more

Many conventional password rules do more harm than good. For example, a maximum age for passwords results in users having to remember a new password every time and as a result, this rule creates an incentive to choose passwords that are easy to remember. This leads to poorer passwords overall: Months, seasons, or year numbers become a common part of passwords, making attacks much easier.

Instead of forcing users to change their passwords regularly, this should be reserved for cases where there is a reason to suspect that a password may have been compromised.

But also rules about password composition do not necessarily lead to better passwords. Have you ever had a password that ended in 1! or something similar, just to include the mandatory digit and the special character?

Yet which rules really lead to better passwords?

First, the password length, because the number of possible passwords grows exponentially with the length of the password. Secondly, avoiding passwords that have already been compromised and therefore can appear in dictionaries used by attackers.

Some mathematics

We can also support these considerations with numbers. If you are only interested in our recommendation, feel free to skip this section.

In the following we consider the ASCII character set with 26 upper and lower case letters, 10 digits and 33 special characters. To keep the calculations simple, we only consider passwords with exactly 8 characters.

With these assumptions, we can calculate the number of possible passwords without any rules in place:

Now, if we wanted to have at least one character each from the four classes of uppercase letters, lowercase letters, numbers, and special characters, the formula becomes a bit longer:

By limiting the passwords to have at least four character classes, we have more than halved the number of possible passwords.

If we introduce further restrictions, such as no ascending or descending number sequences, we further reduce the possibilities. This reduction may be justifiable in exchange for better passwords. But do the rules really lead to better passwords?

For the next consideration, we include the human factor: What happens if we assume that the user follows a simple strategy to meet the requirements? We assume that the user has chosen a password that starts with an uppercase letter, followed by only lowercase letters, and ends with a digit and a special character:

With this strategy, only slightly more than one $\frac{1}{30,000}$ of the possible passwords are left. This is comparable to a password that consists of only lowercase letters ($2.1\cdot {10}^{11}$ possibilities) and significantly worse than, for example, a password that consists of 10 lowercase letters ($1.4\cdot {10}^{14}$ possibilities). The security gain from the rules is negligible compared to the length of the password.

Password length

If the password length is the relevant factor, this naturally leads to the question of what the best password length is. This is where security considerations and practicality collide: while 8 characters is already vulnerable to offline attacks even with a completely random password, the longer the password, the more difficult it becomes to remember.

While a minimum length of 10 or 12 characters would obviously improve the security margin, the length already makes it difficult for users to remember a multitude of passwords. For users, the solution here is a password manager that makes passwords of 20 or more characters manageable without additional effort. Unfortunately, developers cannot rely on this.

To make offline attacks more difficult, it is essential to use suitable password hashing algorithms, such as Argon2 or PBKDF2, and a salt. At the same time, passwords should not be used as the sole factor for authentication, especially for applications with higher protection requirements. Two-factor authentication (2FA) significantly reduces the risk of a successful attack on authentication and should thus be supported by all applications by default.

Best Practice

A good basis for password rules are the recommendations of NIST Special Publication 800-63B, which can be roughly summarized as follows:

• Passwords must contain at least 8 characters.
• No limit on maximum length (or at least 64 characters).
• All printable ASCII characters must be allowed.
• Unicode characters should be allowed.
• Known weak passwords should not be allowed.

Known weak passwords include:

• Passwords from dictionaries.
• passwords from known data breaches (e.g. https://haveibeenpwned.com/Passwords).
• Passwords that are frequently used in bruteforce attacks (e.g., https://github.com/lutrasecurity/bad-passwords).

In general, passwords alone do not provide sufficient security in the long term. Therefore, any system that offers authentication by password should offer users the option for two-factor authentication.