The evolution of the NIST password complexity rules: a mandatory step before a passwordless world?

Using passwords introduces both a large attack surface (phishing, brute force, password spreading, rainbow table, etc.) and a poor user experience. As a result, passwords have been denounced in favour of passwordless technologies for several years. However, passwords remain commonly used due to both technical and human factors and are likely to remain so for the next few years.

What should we do with passwords until they are no longer in use? How can we minimise the impact of what is the main sticking point in the user experience, whilst improving the security posture of our organisation?


Why are passwords so common?

Since ancient times, passwords have been used as the means of entry to secret clubs and underground factions. The historical access management system of “if I have the secret, then I have the right to entry” has since transformed into a way of proving one’s identity – “if I have the secret then I am who I say I am”. Inserting characters in a certain order known only to the user with right of access, thus has become the solution to allow them to prove their identity.

Although the weaknesses of this system were quickly realised, if the computer systems were not connected and therefore, they required physical access, the attack surface remained limited in comparison. The password has therefore become a pillar of IT security and is used in almost all services requiring user management.

However, the arrival of networks (the Internet, in particular) and the resulting growth in exposure has turned password-related security weaknesses into real vulnerabilities.


How did we come to burden the user with such complexity?

The number of possible attacks on passwords has gradually led security experts to increase the number of safeguards designed to protect passwords.
As a result, a certain number of measures are now taken to secure passwords and their associated processes, making the user experience even more complex. For instance:

  • Minimum number of characters
  • Complexity (1 number, a letter, a special character, etc.)
  • List of forbidden words
  • Recommendation of password uniqueness between services
  • Periodic renewal & history

These rules, largely based on past National Institute of Standards and Technology (NIST) recommendations, NIST.SP.800-63-2, 2015, and that could be found in most of framework (UK, French, etc.) negatively impact the user experience. Often unintuitive and different from one service to another, users sometimes find it challenging to understand them: lack of clear explanations on the expected complexity, no display of incorrect attempts remaining before the account is locked, or variations in access channels resulting in differing experiences (accessibility of some special characters different from one terminal to another, for example: the “§” character on an iPhone or an iPad).


And is it effective?

Despite all these measures, the password is still criticized for its low level of security, because it is based on two principles that are not compatible with a high level of security.

The very principle on which the password is based, the shared secret, leads to two attack vectors:

  • Data in transit – transmit the secret regularly: the password can then be leaked or stolen via a proxy that is too informative in its logs, caching in the shared memory of a smartphone, or keylogger-type malware, etc.
  • Data at rest – storing the enterprise password to verify it: the use of storage methods with low security levels is still too common (reversible encryption instead of non-reversible hash, old sha-1 type protocol, no salting, or worse, plain text storage).

And even more recent hash protocols remain potentially fallible in the face of current computing power. Thus, even with a recent hash protocol like sha256, retrieving an 8-character password from its hash will take… less than a day.

Attackers can then directly retrieve the password, ignoring its complexity (except for the length for brute force and storage if using a recent, robust, and regularly updated hash protocol).

The volume of human beings in the system and their capacity to make mistakes has an even greater impact:

  • We are bad generators of randomness: this explains the lists of the most common passwords that appear every year. And, with strong constraints on creation, the possibilities of variations are lower, making the level of entropy decrease. The imposed complexity is counterproductive.
  • We have a bad memory: encouraging practices that lower the level of security (use of a derivative or even the same password – 63% of users admit to this practice – post-it notes on the desktop, unencrypted .txt files, etc.)
  • We are easy to trick: phishing, spearphishing and social engineering are widespread attack vectors.

If the user provides his password to the attacker, it does not matter if it is 60 characters long or consists of letters from different alphabets.

The complexity of the password has no influence on the most common types of attacks, and therefore only causes inconvenience to the user.


What to do?

As password issues are not new, there are several possible solutions that can be used in conjunction to reduce the problems and their impacts. The delegation of authentication to third-party services (social login, enterprise IAM, etc.), and the implementation of Single Sign-On have facilitated user experience and limited password replay/transitions and places where the password is stored at rest.

The development of second authentication factors (OTP SMS or mail, push notification, hard tokens, etc.), the most recent ones being less intrusive and less disruptive, ensures better security.

In addition to these solutions, which are already proven and widely deployed, and in anticipation of being ready to enter the passwordless world, which alone is a huge project, NIST and other frameworks recently revised their recommendations regarding the required complexity around passwords (NIST.SP.800-63b, 2017, NCSC UK, Password policy: updating your approach, 2018 for example).

So, from a user point of view, the constraints on passwords have been reduced to a minimum number of characters (8) and the rejection of common/compromised passwords. In exchange, user-facing measures offering more freedom to the user are often recommended:

  • All Unicode characters, including space, must be allowed, without being forced
  • The maximum size limit must be at least 64 characters
  • Rotations should no longer be time-based, but only in case of compromise
  • The user must have at least 10 attempts before being blocked
  • Different user experience improvers are to be considered (clear information on the expected complexity, ability to display the password during input, ability to paste values, etc.)

These new recommendations aim to guide users towards the use of longer and more random passwords by reducing constraints. They can be accompanied by the raised awareness and usage of safe passwords, preventing the user having to remember too many passwords.

The remaining recommendations, mandatory to ensure security levels are not reduced, reinforce some of the aspects mentioned above. Those measures also aim to strengthen transmission (encryption, etc.) and storage (hashing, salting) to increase the level of security of the company’s activities and to prevent the use of certain practices that lower security (use of secret questions for password reset, etc.).



If the elimination of the password is a goal, its eradication is far from complete. It is necessary, before reaching this goal, to implement measures that aim to secure user data (for example by implementing multi-factor authentication on sensitive services) while facilitating the process and users to protect themselves. This includes the implementation of elements that prevent the user from logging in too often or creating too many passwords, but also by redesigning the complexity of passwords in order to increase the randomness, and by upgrading the technical means of transmission and storage.

Using existing processes to prepare for future changes is also essential. For example, redesigning the password recovery path to move the user toward passwordless authentication can help make a smooth transition to greater security while improving the user experience.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top