Does a password policy with a restriction of repeated characters increase security?

Question

A security value called Restriction of Repeated Characters for Passwords (QPWDLMTREP) can be configured in IBM i. If QPWDLMTREP has a value of 1, then "the same character cannot be used more than once in a password, even if the repeated characters are not adjacent. A system can be further configured such that the test for repeating characters is case-insensitive.

Would use of this password policy make a system more secure?

Answer 1

In general, no, such a policy is counterproductive to security. While many weak passwords use repeated characters, so do many strong passwords... and many weak passwords don't.

Some reasons not to use such a policy:

• It reduces the brute-force search space (though not by an amount that is really destructive for moderately long passwords)
• It increases the risk that users will pick weak passwords that conform to the rules (e.g. qwertyuiop), when otherwise they'd use a better password generation scheme that doesn't
• It prevents very long passwords/passphrases, if you disallow repeats at all (any remotely sane policy wouldn't be that draconian, though, and merely disallowing consecutive repeats doesn't have this particular problem)

Ultimately, pretty much all password policies are aimed at two things:

• Users should use a novel, high-entropy password (one that hasn't been used before, ideally by any user on any site, and that isn't more likely to be chosen than a huge pool of other options) so that brute-force attacks (even aided by knowledge about common password strategies) don't succeed.
• Users should use a password that can't be predicted even by a knowledgeable attacker (one that, even if the attacker knows every other password the user has ever used, they wouldn't be able to guess in reasonable time)

Unfortunately, nearly every password "quality" requirement dating to before a few years ago - and a whole lot of them since - do terrible jobs of achieving these goals. Character type and repeat requirements (or restrictions) do nothing except get people to "game" the rules (e.g. "Pa$sw0rd"). Minimum length does help, but is insufficient (and you should not enforce a maximum length, unless required for technical reasons).

---

I'm not familiar with the software you're using, so these are some general recommendations for attempting to enforce password quality, generally based on sources such as NIST.

The recommended fix for the problem of novel passwords is to use a list of known passwords from elsewhere - usually collected from compromised sites that had weak password security - and reject any password on it. Some of these lists are quite long - e.g. https://haveibeenpwned.com/Passwords has a list of over 600 million unique compromised passwords - and site owners can and should reject any password on such a list. You might even want to try "normalizing" the breached password list and the users' password candidates (e.g. "Pa$sw0rd" -> "password", removing capitalization and reversing common substitutions), since you want to catch obvious modifications of passwords even if they haven't been seen in a breach yet.

Addressing the problem of unpredictability is harder. Generally, you end up wanting to block as much information as possible about the user, site/app, date, and any other predictable-to-an-attacker information. So, don't let users use their name, username, age, address, email address, date of birth, or any other information about themselves (to the limits of your knowledge) as part of their password. Similar, don't allow your site, app, or company name, any part of the current date, or so on. Such filters should be fairly narrow - the goal is to block anything a attacker would guess, not everything that plausibly could be related to the user - and match any part of the password, not just the start or the whole.

In combination with the block on compromised passwords this tends to result in fairly novel and unpredictable passwords. Combine that with expensive salted password hashing (ideally something with a high and tunable memory cost, to interfere with parallelization of brute-forcing) and ideally a second factor, and you are well on the way to strong authentication.

Answer 2

The answer is both 'yes' and 'no' depending on the context.

The intent of such a restriction is explained in the link. The consequence is that a password needs to randomly generated to be more likely to satisfy the policy. And randomly generated passwords are more secure than password people come up with to remember.

But...

The lack of repetition means that it would be easier for someone to bruteforce the random password (due to the reduced number of combinations), thereby reducing the benefit of the random password. But it is still more likely to produce a more secure password than one that someone could reliably remember.

However ...

If this is a password that someone needs to remember, then this creates an even bigger problem. Given research into such things, a person will either:

• find a password string that will satisfy the policy (which will initially be good and strong), or
• create a "keyboard pattern" password

But then, if it needed to be changed or refreshed, they would simply add a character (most likely), change a character to the random password, or shift the keyboard pattern up or across the keyboard. This is why we get passwords like Password1, Password2, and 1q2w3e4r then 2w3e4r5t, etc.

This means that if the password is leaked or compromised, an attacker can easily guess the password when it changes. This makes the password restriction unintentionally insecure.

This is one reason why the advice for years has been to encourage people to generate a strong random password (e.g. "3 random words") and not to force them to change it on a schedule. People don't tend to make brand-new passwords but merely alter the existing one.

So...

Such a restriction is intended to force people to more likely create a random password, initially. But the consequence is that it can result in very insecure passwords later on.

The better approach is to force very, very long passwords, teach people how to create such long passwords securely and provide tools and support to make such a long password viable for practical use.

Answer 3

I mostly wanted to add some math to the reduced search space argument. As an example, suppose passwords are generated from the 26 letters plus the 10 digits, so 36 characters and are exactly 10 characters long. Then if you allow repetitions there are $36^{10} = 3.656158e+15$ different possible passwords. If you exclude repetitions there are only $36!/26!=9.223933e+14$ different possible password. So you loose about a factor of 4 in this example.

If you allow more possible characters, the loss in entropy gets smaller, if the passwords are longer the loss in entropy gets bigger.

I think the worst case scenario for this restriction can happen for a user that has a password manager or similar software that generates long, secure, random passwords but these often fail this restriction. If the user then gives up after a few attempts and uses '12345' as their password because that satisfies this rule the well-intentioned rule had exactly the opposite of the intended effect.

Answer 4

Short answer: No.

It reduces entropy

Let's say that you want a 10-character password, selected from an alphabet of the 94 printable ASCII characters (excluding space).

With no restrictions on duplicated characters, there are 94¹⁰ ≈ 5.386 × 10¹⁹ possible passwords. If the characters are selected truly at random, this works out to 65.546 bits of entropy.

With duplicates not allowed, there are P(94, 10) ≈ 3.281 × 10¹⁹ possible passwords, or 64.837 bits of entropy.

So the restriction costs you 0.709 bit of entropy. Admittedly, that's not a lot, but it's still a reduction.

It doesn't do much to prevent the use of bad passwords

In Wikipedia's list of the 10,000 most common passwords, 3542 of them follow the rule of having no repeating characters. So it wouldn't do anything to stop people from using passwords like 123456, 12345678, or qwerty.

True, it would prevent 6458 of these common passwords, including password, 111111, or 123123. But you could accomplish the same thing by just having an explicit blacklist of bad passwords.