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?

  • 6
    Wait it literally says this on the page you linked. I'm sorry, what's the question?
    – foreverska
    May 1, 2023 at 0:37
  • 17
    @foreverska IBM say that their policy provides additional security, but I'm asking this community if they agree. I can understand blocking adjacent repeated characters to avoid something like "passsword", but a value of 1 means that once a character has been used in a password, it can't appear anywhere else in the password. This must dramatically reduce entropy. When using bitwarden.com/password-generator on default settings it takes several tries to generate a compliant password, even without case-insensitive matching.
    – John Haire
    May 1, 2023 at 1:29
  • 5
    ... For simplicity, suppose 26 lower case letters are allowed. If any letters are allowed, and if password length is 15, then the attacker would need for brute-forcing in the worst case 26^15 tests. Where as if repeated characters are prohibited, then the number of candidates to test will be 26*25*24*23*22*...*12. Thus, such restriction reduces the number of needed tests in 166 times. It is still a huge number. But it shows the principle.
    – mentallurg
    May 1, 2023 at 3:50
  • 22
    This is a really bad policy, because it blocks high strength passphrases such as DiceWare style, due to running out of vowels (consonants become problematic in passphrase testing as well, but the theoretical analysis is much much simpler for the vowels).
    – Ben Voigt
    May 1, 2023 at 19:51
  • 17
    This sounds like a terrible policy. A very likely result is that users are going to be very frustrated when trying to come up with a password, and you'll end up with many users having password abcdef123456 or q1w2e3r4t5y6 or something equally simple, just because they had trouble coming up with a password that didn't have repeated characters.
    – Stef
    May 2, 2023 at 9:56

4 Answers 4


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.

  • A phenomenal tool that can be used to test/enforce password security is zxcvbn. It checks for many of the issues that are mentioned here. However you should also add additional rules depending on your situation. Try it here: lowe.github.io/tryzxcvbn
    – Unknown
    May 6, 2023 at 2:39
  • 1
    Oooh, I like that. Though it really should use a longer common password dictionary than 30k, IMO. And yes, you really want to block - or at least completely discount from the password quality - common strings specific to the app, user, date, etc.. I recommend blocking them entirely; if somebody is using such strings, it's more likely that they're trying to use the same "strong" password, plus a tag, on every site, and that's not actually secure against an attacker who has seen other passwords the user used. Also, zxcvbn does not appear to recognize dates at all.
    – CBHacking
    May 6, 2023 at 13:05

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.


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.


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.

  • 8
    And of course, an obligatory XKCD to illustrate this answer: xkcd.com/936 May 1, 2023 at 13:17
  • 1
    Perhaps a limit on the fraction of repeated characters might be reasonable. A 20-character password is nice, but not so much if 10 of them are all a.
    – Barmar
    May 2, 2023 at 14:29
  • Or maybe a restriction on runs of repeated or consecutive (either alphabetically or QWERTY-adjacent) characters.
    – dan04
    May 3, 2023 at 17:08

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.

  • 2
    Thanks for the math (and good point about people giving when generating strong passwords gets blocked by overzealous policies). I want to add, though: VERY few people are going to use a 10-character truly-random alphanumeric password. The usual tools (e.g. first letters of a sentence) don't have anywhere near full entropy for their length due to biases in English. The best human-compatible way to get equivalent security is passphrases of random words ("diceware"-style, as popularized by xkcd.com/936) and those are going to be utterly impossible to make securely long under such a policy.
    – CBHacking
    May 2, 2023 at 10:24
  • 1
    I would think a good rule would be to require that a password must be of at least N, with at least M different characters, often with M typically being less than N. For example, minimum length 8, with 6 distinct. No harder to understand than a rule requiring all characters be distinct, but most good passwords that satisfy the length requirement should also satisfy the distinct characters requirement.
    – supercat
    May 2, 2023 at 15:26
  • 2
    Exactly! Forbidding certain patterns reduces the password space and makes them inherently easier to crack. That said, a policy should forbid all or most digits to be the same (together with a load of other criteria like birth dates and dictionary words) because it's what people would likely do if left alone and hence something an attacker would check. May 3, 2023 at 15:50

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 9410 ≈ 5.386 × 1019 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 × 1019 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .