Password Best Practice

Last modified 09 Oct 2024 14:22 +02:00

Passwords are still the most common type of memorized secret authenticator. This page provides general information regarding proper use of passwords.

Password Policy

There is a lot of dissonance in the cybersecurity community when it comes to recommendation regarding proper use of passwords. Traditional wisdom regarding use of passwords was to use the most complex password possible, forcing its change as often as possible. However, this was found to be a counter-productive advice. Requirements for complex passwords make it almost impossible for users to remember the passwords, motivating them to write down the passwords and/or re-use the same passwords on multiple sites. Furthermore, enforcement of frequent password change leads to predictable password patterns, inconveniencing the users without any real increase in security.

Therefore, the recommendations regarding password policies is changing in last several years towards better usability. Following recommendations are compiled based on recent security standards (e.g. ISO/IEC 27002:2022), best practice (e.g. NIST SP 800-63B) and experience. We currently recommend to implement following measures:

  • Passwords should be at least 8 characters long when chosen by the user, 6 characters long when generated.

  • All printable (ASCII) characters as well as space should be acceptable in the password. Spaces should be allowed, to encourage use of passphrases. Punctuation and similar characters should be allowed as well, as those are commonly used by password managers.

  • Black-list (dictionary) of simple-to-guess and compromised passwords should be applied. Also, check for presence of service or user data in password, e.g. presence of username, user’s first or last name, name of the site or service, combination of numbers corresponding to user’s birthday or year of birth, telephone number, etc.

  • Password length is considered a primary factor that determines password strength. Encourage use of long passphrases rather than short passwords. The system should allow passwords at least 64 characters long. It is reasonable to have a limit, to avoid denial-of-service (DoS) by attempting to use extremely long passwords. Yet the maximal length limit of password should be quite high (e.g. 3000 characters).

  • Authentication rate should be limited, to avoid brute-force attacks. The best approach is to temporarily lock-out the password after several failed attempts, or to gradually increase lock-out time in reasonable increments after each failed attempts. Having a forced lock-out period after each failed attempt usually opens up opportunity for denial-of-service (DoS) attacks, therefore it is not recommended.

  • Detect ambiguous situations when checking password after password change. E.g. presence of non-printable characters, presence of several subsequent spaces, space at the beginning/end of password and so on. When detected, warn user and/or refuse the password.

  • Never store clear-text passwords. Always store passwords in hashed (and salted) form, or provide similar level of protection. This provides small amount of additional protection during attack. However, it is relatively easy to implement, and it provides considerable level of protection against unintentional exposure of passwords to system administrators (e.g. in log files or database trace files).

  • Enforce password change after security incidents or when otherwise detected that the passwords are no longer secure.

When generating passwords:

  • Generate a passphrase rather than password. Use words and spaces, forming a reasonably long random sentence.

  • Make sure to avoid ambigious sequences, such as double spaces.

  • When generating a non-passphrase password, avoid using characters that are easy to get wrong, e.g. 0 (zero) and O (letter O), 1 (number one) and l (lower-case L) and so on. Compensate by generating longer password to keep approximately equivalent entropy. This is essential in situations, when the password is likely to be printed and re-typed from the print (e.g. initial passwords for devices).

  • Avoid use of fixed or predictable passwords, even as short-term or initial passwords. Such passwords, when established are very unlikely to ever get changed. Even enforcing password change on first log-on does not improve the situation, as users are likely to choose predictable variant of original password. Avoid use of fixed "factory" passwords for devices and production services at all costs, as those create low-hanging fruits for automated attacks on large scale. Avoid use of user’s names, birthday, year of birth or similar data, as they are usually very easy to learn (e.g. by social engineering). Fixed and predictable passwords may be used only when coupled with additional security measures that are designed to strongly limit the risk (e.g. demo service without sensitive data available on localhost only).

Given the traditional wisdom, it may be surprising that there are no password complexity requirements, e.g. requirement for combination of upper-case, lower-case letters, numbers and punctuation. This approach is not effective. It makes password very hard to remember (poor usability), yet it does not significantly increase the security. E.g. a user that would choose alice as password is likely to choose Alice if upper-case letter is required, Alice1 if a number is required and Alice1! if punctuation is required. As such, password complexity requirements are not a good security trade-off.

Similarly, there is no requirement for password expiration and/or forced regular change of passwords. When forced to change the password, users are likely to choose predictable variants of original passwords, use passwords used on other sites, or write down the passwords, resulting in increase of overall risk rather than decrease.

PIN

Personal identification number (PIN) is almost completely similar to password, except for two details:

  • PINs are usually numeric

  • PINs are often randomly-generated, users are not choosing them.

Recommendations for PINs are as follows:

  • When PINs are randomly-generated, they should be at least 6 digits (characters) long.

Future of Passwords

It is perhaps no big surprise that the best recommendation regarding passwords is not to use them at all. There are attacks that even the strongest passwords cannot survive, such as keystroke logging, phishing, and social engineering attacks. Even strong passwords provide only a very limited protection against off-line attacks on leaked password databases. Overall, when combined with the human nature, passwords are inherently insecure.

Unfortunately, we have not found any silver bullet, any easy solution that would completely replace the passwords so far. However, there are ways to make passwords considerably more secure by combining them with other authentication mechanisms. For example, multi-factor authentication is using several authentication mechanisms to supplement security deficiencies of passwords. Also, there are other techniques that aim at replacement of passwords, such as authentication based on public-key certificates (X.509) or passkeys. However, many of these techniques embed some parts of password-like mechanisms in them, such as use of PINs.

Passwords are here to stay, at least for now. Whether we can go "password-less" in foreseeable future is a big question that does not have any clear answer yet.

Was this page helpful?
YES NO
Thanks for your feedback