Restrict password generator character use quantity

I would like to restrict the password generator’s use of a given character to a customizable amount. I personally prefer my passwords to only use a character a single time and only one use between capital and lower case letters, so no passwords containing both “g” and “G”.

The current way the generator works, I would have to generate multiple passwords to find one that did not contain repeat characters, often times containing the exact same character.

For example, some generated passwords:
QB^$DDe99Xm8@%jG (two D)
!2%yt9#6rDc6Lgtk (two 6)
yZ^6%47k^ry7LwQU (two 7)
9jq#2%E$csQ97@!Y (two 9)
QR%^Ymi&&8%G8UT2 (two & and %)

These passwords were all generated back to back with minimum number and special set to 3 and avoiding ambiguous characters. I find it odd that so many passwords can be generated and the overwhelming majority of them always have a duplicate character.

1 Like

So you want to make generated passwords less random and thus, less secure?


I’m genuinely unsure how you come to that conclusion so I have no idea how to explain my idea of you being wrong? Please go into further detail.

1 Like

It ist very random, if no one can predict how many times a character appears in a password. So I agree with PossibleGhost: it would be less secure, if there would be a (possibly detectable/analysable) rule, to only use every character once.

The password generator doesn’t intentionally repeat same characters, so that happens randomly. Also, including more rules about how characters can appear in a generated password will make these passwords less random, which is not not good when creating passwords. Besides, even if you find two characters repeating in the way you have described doesn’t make the password automatically any less secure, even if it may appear so to the human eye. That may be true for human-generated passwords but not for machine-generated ones.


Okay, thank you for the explanation. That does make sense after you’ve explained it.


May I ask, with a 16 character length, is having a unique character rule an issue? I’ve been using a separate password generator with it enabled but it also has a customizable special character entry to change what the special character pool is to select from, which I’ve populated with most of the characters outside of punctuation.

The reason I posted this request in the first place was that the other generator I use has a strength meter with a readout saying how many bits strong a given password is. I consistently get a strong rated 99 bits with unique characters, rarely get 96 bits but when I disable unique characters rule, the generated passwords potentially drop down to medium rated 61 bits. Granted, most of these passwords look more or less fine outside of the rare repeating character string (I’ve seen it generate “DYDY” in a recent password).

I have the feeling none of my passwords are an issue but is this an option that is recommended to be disabled?

Thanks for taking time to explain to me.

To answer your question, with 16-character passwords, I don’t see that having the kind of unique character rule you are proposing is a big issue. However, the way this other password generator you’re using calculates the password entropy is problematic because it changes the entropy based on the characters of the created password. So, if it notices repeating characters, it will lower the entropy. However, password entropy will always stay the same if we use the same set of characters to create randomly-generated passwords. Also, most of these password strength meters are not really a reliable way of evaluating password strength in the first place. The only good one I have found is from Passwordbits, which can show you the actual entropy of randomly generated passwords.


@PossibleGhost: I’m not so sure, that entropy doesn’t change with a change of characters. For example, in theory, even a readable word would be something that could be part of a password generator generated password (as an example, “ate” comes to my mind - short word, which could happen as part of the randomness). And with that, the entropy would be lower. It would be odd, if it wasn’t. (but I think this also depends on how the generator assesses entropy)

@TortuousAugur: When you already use a password manager, I would encourage you to choose longer passwords. When the account provides it, the password could be 20, 30… 60 or maybe 120 characters long. It doesn’t matter as long as the password manager manages it for you (and if you ever have to type it in manually). - The longer the password, the better the entropy. (as a general rule)

16 characters should be seen as the absolute minimum length these times, I think. :thinking:

Using 16 characters for your passwords is still perfectly fine to use if the password is randomly generated. By using Bitwarden’s default password generator rules, a 16 character password would have around 95 bits of entropy that will be more than good enough for securing your accounts. If you’re more interested in password strength, I would suggest that you read these two sources I have linked below. Also, just so you know, suggesting passwords that go over 42 characters and thus, exceed 256 bits of entropy, don’t make any sense as you can’t gain any additional security since the encryption key itself can’t handle anything more than that.

Thanks, I will look into it. I don’t claim to be an expert.

The article from the 1Password Blog may be outdated as it seems to be from 2018. ?! (edit: oh, I just saw it was last updated in the end of 2021. Nevertheless, I remain sceptical with 16 characters…)

Only one thing I would also consider: computing power get’s better every year. And quantum computing seems to be no clear thing as of now - some say it is overstated, some say encryption is in danger.

There is a saying I really heard not long ago (I just started last year with setting up my first password manager): store now, decrypt later.

I hope it’s not a conspiracy theory :wink: : Maybe criminals, maybe intelligence agencies seem to store data - and who knows what can be decrypted in ten years or else. If this is true or not: I like to think of the future and want my date extra secure (paranoid level :rofl:) becauso who knows what can be decrypted in a few years or decades, what someone stored now if he or she get’s it in his or her hands.

BTW: Bitwarden also says, 14 to 16 characters should be the minimum:

If someone is an expert here, I would like to know more about:

I never heard of a 42 characters / 256 Bits of Entropy “limit” in regard of encryption/encryption keys.

Can someone validate this? Or knows a source, where you can read more about that?


Since there may not be enough users needing this particular option for their password generation, a potential variation would be allowing the user to configure/input a snippet of code (javascript function, or whatever is most amenable to consumption by bitwarden) that would return whether the generated password is acceptable. Then bitwarden can generate passwords (up to some likely sane limit, maybe like 1k or 10k?) and pass them into the function to see if it was acceptable.

That would give people a chance to implement whatever kinds of arbitrary restrictions they want, at least if they can make or find the snippet to do so.

Admittedly, this isn’t strictly needed to be supported by bitwarden. Certainly today anyone could make a userscript for Strong Password Generator | Bitwarden that would do the same and each time their script/snippet rejected a password, it ‘clicked’ the “regenerate”.

Definitely not as user-friendly as having it be a built-in option/feature though!

@TortuousAugur not sure if would cover the case-insensitive check, but not reusing the same character seems to be covered by Password Generator Plus if you needed a fallback option in the mean time.