Why most password requirements are silly. Also, here’s our flavor

7 min readAug 31, 2023

If you intend on building a secure application, you should enforce strong password requirements to prevent bad actors from easily breaching your users’ accounts.

Having revamped our password requirements twice as part of our work at Infisical, I discuss everything about password requirements in this article from what’s silly about modern password requirements to NIST recommendations on how to make good ones.

What are password requirements?

To begin, a password requirement is any rule that a password must conform to. For instance, a requirement might be to include at least 1 uppercase character; a more stringent requirement might combine multiple rules together.

Having password requirements are important to mitigate risk since people are terrible at choosing good passwords. In fact, the infamous RockYou incident back in 2009 confirmed this fact when 32 million user accounts got breached and we learned just how terrible people were at choosing passwords — they were stored in cleartext. Consider these top six most commonly used passwords found during the breach:

princess
rockyou
1234567
12345678
abc123

Unsurprisingly, by using sophisticated methods targeting leaked passwords and common patterns, bad actors routinely exploit such weak passwords and gain access to accounts wherever possible.

That said, by considering guidance set forth by the National Institute of Standards and Technology (NIST), various regulatory/compliance frameworks, and your specific circumstance; you can make it difficult for bad actors to brute-force passwords hopefully without sacrificing user experience.

Why are password requirements confusing?

From running into silly password requirements to seeing memes everywhere about it and working with penetration testers, we’ve realized that making good password requirements is challenging and perhaps unclear to developers and security professionals.

In fact, there is a whole website called dumbpasswordrules.com dedicated to listing sites with “dumb password rules,” not to mention guidance from various compliance agencies/frameworks that contradict one another — More on this later.

The issue is that we struggle to define rules that strike a good balance between security and user experience, two requirements in themselves that lay in opposition to one another.

Consider this:

A strong password is difficult to breach but unlikely to be memorable.
A weak password is memorable but likely to be breached.

As a result, we often come up with password requirements that, at first glance, seem effective but end up being both weak and not memorable. For instance, we might enforce several rules like:

The password must contain at least 10 characters.
The password must contain at least 1 uppercase letter, 1 lowercase letter, 1 number, and 1 symbol.

Here, the value Password1! actually passes as a valid password under this set of rules and yet it’s clearly not a great one. For one, it’s a low entropy value but it also forces users to remember yet another password variation amongst others that they have elsewhere like Password1!a .

So what makes a good password? Spoiler alert: It’s all controversial but there is guidance on this topic.

Making good password requirements

The NIST recommendation

To understand what seemingly makes a good password, we turn to NIST and specifically NIST Special Publication 800–63B from 2017 that provides fruitful observations in Appendix A:

Password length: Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.
Password complexity: Users respond in predictable ways to the requirements imposed by composition rules, rendering requirements less effective than intended. Additionally, complex requirements are less likely to be memorable and more likely to be written down or stored electronically in an unsafe manner.

Here, NIST tells us that length and complexity requirements increase the difficulty of memorized secrets (i.e. passwords) but at the expense of user frustration and, as a result, users often work around these restrictions in a way that is counterproductive. Beyond observation, NIST does provide more specific guidance in section 5.1.1 on what password requirements and implementation gotchas to look out for.

Regarding password requirements:

Users should be able to create passwords that are at least 8 characters in length with support for at least 64 characters in length.
Automatically-generated passwords should be at least 6 characters in length.
All ASCII/Unicode characters should be allowed, including emojis and spaces.
Passwords should be scanned and considered against password breach databases, dictionary words, repetitive or sequential words, and context-specific words (e.g. username). If a match is found, then the password should be rejected.
Passwords should not impose composition rules, considering earlier that users find ways to work around these restrictions.

Regarding password/authentication implementation best practices:

Passwords should not have hints.
Password strength-meter or feedback is recommended to be shown to users.
Rate limiting should be implemented to limit the number of failed authentication attempts.
Passwords should not be required to change at intervals; they should only change in the event of emergency compromise.
Passwords must be properly salted and hashed using a suitable one-way key derivation function (KDF) such as PBKDF2 and Balloon.

To note, the above list is not-exhaustive and you should consult NIST Special Publication 800–63B yourself for the full rcommendation.

Additional password considerations

Beyond NIST, the topic of creating good password/authentication procedures and requirements may concern regulatory and compliance frameworks like GDPR, ISO 27001, ISO 27002, PCI DSS etc. If these frameworks are relevant to your platform, then it may be necessary to consult them as well.

For instance, some criteria for PCI DSS include:

Passwords must be at least 7 characters in length.
Passwords must contain numeric and alphabetic characters.
Users must change their passwords at least every 90 days.

But hold on.

Didn’t NIST advise us against changing passwords at intervals?

Well, it turns out that password requirements are somewhat contextual and should be evaluated on a case-by-case basis. Put differently, there is no one standard that satisfies every criteria; even if there was such a standard, then it would likely be outdated in the following years.

Here, the reasoning behind NIST’s guidance is grounded in user behavior and empirical data. It has been found that when users are forced to change passwords frequently, they often resort to predictable patterns or incremental changes to their existing passwords, which can be easier for attackers to predict. On the other hand, the PCI DSS requirement is tailored to the protection of payment card data, and its guidelines reflect the risk appetites and considerations of the payment card industry and environment.

What do you propose to be good password requirements?

Our understanding is that a good set of password requirements relies primarily on password length and the appliance of rules that cross-check values against common patterns/passwords (e.g. PII, repeat/consecutive characters, etc.) and leaked passwords in password breach databases; in addition, mechanisms like rate limiting are important to implement at authentication time to mitigate the possibility of bad actors brute-forcing password combinations.

A good set of password requirements is not, however, contingent on having 69 rules in place since doing that has the reverse intended effect: People end up forgetting their passwords.

Lastly, I do want to note that, in the ideal world, we’d be moving away from passwords to semi-password-less or password-less authentication mechanisms. Whether it be single sign-on or biometrics like Touch ID and Face ID, these methods rely less so on users to have to memorize bizarre passowrd combinations. That said, for the time being, the universality of passwords still demands us to support the method and have recommendations for it, hence this article — noted by NIST itself.

How we did it at Infisical

In our second iteration of revamping password requirements for Infisical, after much consideration of various requirements, we realized that we just couldn’t satisfy every piece of guidance out there. The reality is that standards keep evolving and this is why every platform imposes its own set of standards.

That said, we considered the guidelines set forth by NIST, our role in the development/infrastructure ecosystem as a secret management platform, and user experience in making our own flavor:

Passwords must be between 14 and 100 characters in length.
Passwords must contain at least 1 letter and at least 1 number or special character.
Passwords can contain at most 3 repeat or consecutive numbers/letters.
Passwords can contain all ASCII/Unicode characters including emojis and spaces.
Passwords cannot be of low entropy by select criteria such as being an email address, URL, date, generalized phone number, passport number, driver’s license, social security number, etc.
Passwords are scanned and considered against password breach databases. If a match is found, the password is rejected. We implement this one with the help of the “Have I Been Pwned” (HIBP) API, which checks the password against around 700M breached passwords, in a privacy-preserving way.

Closing thoughts

Overall, password requirements are still confusing in 2023 and rightfully so, given that it so often evolves and contradicts one another. That said, by heeding guidance from credible sources like NIST and adapting it to your own use-case, you can design suitable password requirements that are difficult for bad actors to brute-force hopefully without sacrificing user experience.

— -