Password Generator: How does changing 'Minimum numbers' and 'Minimum special' affect entropy?

[TheBestPessimist]

We have those 2 settings in which we can decide the minimum number of characters which are changed.
The way they work is as follows (assuming 128 char password length):

• If i set both minimums to 0, then i will get passwords with all 128 characters from a-zA-Z
• if i set both minimums to 1, then i will get passwords with at most 126 characters from a-zA-Z
  • and also at least 1 character from 0-9 which replaces a-zA-Z (but i could get more than 1)
  • and also at least 1 character from !@#^&* which replaces a-zA-Z (but i could get more than 1)
• if i set both minimums to 7, then i will get passwords with at most 114 characters from a-zA-Z
  • and also at least 7 character from 0-9 which replaces a-zA-Z (but i could get more than 7)
  • and also at least 7 character from !@#^&* which replaces a-zA-Z (but i could get more than 7)

What i want to know is how does changing those 2 values affect my password entropy?
Is using 7 7 an increase in entropy or a decrease:

1. compared to using 0 0
2. compared to using 1 1
3. compared to using 9 9 (which is the maximum as of 2024-12-25)

For me it makes sense that increasing the character set (increasing the characters available during pass generation from a-zA-Z to a-zA-Z0-9!@#^&* by using at least 1 1) should increase entropy as there’s simply more things to churn through if the password is brute forced, but what i don’t know is how changing to a greater value than 1 1 affects my password’s entropy?
Is using 7 7 worse for entropy simply because the 364 (7*(26 + 26)) characters in a-zA-Z get reduced into a much smaller search space of 112 (7*16) characters in 0-9!@#^&*?

I guess i should also ask why (is there an increase/decrease/no change), even though i may not fully understand your explanations.

Thank you.

---

The 2 options i’m asking about:

[h.selaps]

My rough understanding leads me to assume that it would REDUCE the entropy because it tell the attacker it increases the likelyhood of any character being a number/special character instead of a letter. The extreme case is that you have minimum numbers = password length, hence only numbers.

[Neuron5569]

Setting both to 0 allows for maximum entropy because the generator can choose from the entire character set of A-Za-z0-9!@#^&* for each character. Setting the minimum to 0 does not mean that characters from this set won’t be selected.

Increasing either minimum value reduces the number of possible passwords that can be generated, and therefore, reduces the overall entropy.

[grb]

@Neuron5569

Setting the minimum to 0 does not mean that characters from this set won’t be selected.

It does, though! In Bitwarden’s infinite wisdom, they’ve implemented the UI so that it unchecks the 0-9 and !@#^&* options if you set the corresponding minimum number to 0. I may not have been so far off the mark in my rant last month, after all…

[grb]

@TheBestPessimist

What i want to know is how does changing those 2 values affect my password entropy?
Is using 7 7 an increase in entropy or a decrease:

Any non-random constraint on the generated password (other than increasing its length, or increasing the pool of acceptable characters) will always decrease the entropy.

For example, we commonly assume that using the full character set (70 characters) for a would generate an entropy of log₂(70) = 6.13 bits/character for random-string passwords. However, this calculation is only valid if every character in the password is selected from the full pool of 70 characters. In Bitwarden’s generator, however, at best (minimum numeric/special set to 1), all but two characters will be selected from the full pool of 70 characters, while the remaining two characters will be selected from much smaller pools (containing only 10 and 8 characters, respectively). This will cause a reduction of the entropy.

The full entropy calculation will have to wait.

[Nail1684]

The generator of the mobile Android app includes special characters and numbers even with “minimum 0”. (version 2024.11.7)

[grb]

Interesting. This is not the way that it works in the browser extensions (new or old), Desktop app, or Web Vault.

[Neuron5569]

That’s embarrassing. I guess I should increase the lengths of my passwords some more. It’s an unexpected weakening (or bug) like this that makes it seem prudent to use longer passwords / passphrases than the experts recommend.

Maybe BW Android native coders don’t agree with the regular coders.

[grb]

@Neuron5569

Maybe BW Android native coders don’t agree with the regular coders.

Another notable difference is that the Android UI displays the full set of special characters avails (!@#$%^&*), while the non-mobile Bitwarden client UIs omit $ and % from the option label.

[Neuron5569]

@anon10321843 @grb

Yeah, the non-native Android version also includes the character sets despite setting the minimums to 0, and it displays the full special character set as well. It’s just an inconsistency (or bugs) across the apps then.

[Nail1684]

I let my unused (old) Firefox extension on 2024.11.2 for now…

It shows the full set for me:

Web Vault also:

Is there already a bug report for that (I didn’t find it)?

[Nail1684]

@Neuron5569

inconsistency

Oh no, that word again… (auto-fill behaviour)

[grb]

@Nail1684

Is there already a bug report for that (I didn’t find it)?

I don’t think it’s a bug, it’s a UI design choice in the redesigned browser extension. Removing two characters allows them to increase the padding.

[Nail1684]

@grb

I don’t think it’s a bug, it’s a UI design choice in the redesigned browser extension. Removing two characters allows them to increase the padding.

Removing two characters in the UI (% and $) that are still used for the generation is not a bug?

[grb]

The characters are only removed from the option label, not from the pool of characters used for generating the password. That’s a UI design choice.

The option labels are only meant as a shorthand representation of the character class, they are not intended to be replicas of the character set. For example, the label “0-9” is only meant as a general representation of numerical characters, even though the actual character set may not correspond exactly to the digits {0,1,2,3,4,5,6,7,8,9} — enabling the “0-9” option will only make available characters in the set {2,3,4,5,6,7,8,9} if the option to avoid ambiguous characters.

[grb]

If you think it’s a bug, would the remedy be to eliminate $ and % from the password generator’s character pool?

[Nail1684]

I understand your general explanation. I guess I don’t like the “inconsistency”. And it’s not very transparent, especially for “newbies”.

The situation with a-z, A-Z, 0-9 is easy to understand - everyone knows the alphabet (putting other transcription systems aside) and numbers and that the whole alphabet with small and large letters - and every number between zero and nine is at least possible.

!@#^&* without any indication of that it represents a class (like " … " or something else - okay, the (three) points as special characters themselves may be problematic, but nonetheless it is a common expression for “there is more”) is misleading I think. It is not self-evident (unlike alphabet and numbers), which other special characters might include that or not.

Or can I expect now, that the generator also includes .:,;"/|_-<>+={[()]}~`?´ as well as some more special characters?

(I personally would like to have all those other special characters included - with an option to exclude some if you needed that - but that’s another discussion and feature request. But, it may have to do with the next point…)

There are still some sites, that don’t accept certain special characters. Again, especially for the “newbies with password managers”, that is not very transparent or self-evident.

(okay, it’s not the biggest problem we have now… but still another thing, that complicates things… probably not for us, as we have an overview about these things)

PS: Okay, I see the problem of “space”:

But even in the overlay prompt, the “true” set of included characters is removed. If at least that would show it… Talk about the extension being more intuitive, getting characters in your password you thought you didn’t include…

@grb

If you think it’s a bug, would the remedy be to eliminate $ and % from the password generator’s character pool?

At this point: either that - or indicate it is not the full set, e.g. !@#^… - or include more special characters and use a second row for !@#$%^&*.:,;"/|_-<>+={[()]}~`?´ and an "Exclude: … "

[Neuron5569]

Not really picking on you, but the symbol label is misleading for me.

You can poll the free password generators web page out there. The ones that are less ambiguous seem to have two strategies: use only description (more space), or use 2-3 character examples in all sets, e.g.

• UPPER, lower, Numbers, Symbols
• BCD, bcd, 234, &*(

O well… Without clarity, it takes more efforts to explain/understand.

[TheBestPessimist]

Thank you all for your replies, I will try to summarize the discussion so far, as there are multiple tangents at hand in the same topic.

This is a live summary of the topic. I will update this from time to time, as the discussion continues.

Updates

• 2024-12-28
• 2024-12-26

1. The entropy

(emphasis mine)

@grb

Any non-random constraint on the generated password (other than increasing its length, or increasing the pool of acceptable characters) will always decrease the entropy.

@Nail1684

setting higher minimum numbers reduces the entropy. I would call that “counter-intuitive” and maybe some kind of note/notice would make sense. […] when I had no idea of entropy […] I thought “more special characters is certainly better…”)

I agree that a notice about this would be useful to educate the people. I guess a link from the apps to a BW blog post explaining the topic would be enough.

The explanation is simple and makes sense to me now, thank you. Leaving the smallest value possible there (without disabling the feature) is the correct thing to do.

2. Should setting the ‘Minimum’ value to 0 disable the feature altogether or not?

The discussion/discrepancy here is that setting the numeric value to 0 for the 2 options has different effects on different platforms. On some platforms 0=feature is disabled, on other platforms 0=the minimum number of characters is 0, so we may have no character from the respective feature.
On the platforms where 0=disabled, in order to enable the feature we must set the number to 1.

The question is what is the right thing to do?
My intuition sais 0=disabled, as that’s how i’m used things to work generally.
But on the other hand, objectively, the feature name is Minimum bla bla, so 0 is a valid option — allow between 0 and X characters from the respective feature character set.

IMO, 0 should be considered a valid option and should not disable the feature because it increases password entropy just a little.

1 might work better than 0 as it aligns with how intuition works. But we should still have a link to a blog post which explains that increasing that number actually decreases your entropy/password strength (as suggested in 1.)

This should be the same implementation for all platforms, to no longer have discrepancies.

Relevant posts:

@Neuron5569

Setting both to 0 allows for maximum entropy because the generator can choose from the entire character set of A-Za-z0-9!@#^&* for each character. Setting the minimum to 0 does not mean that characters from this set won’t be selected.

@grb

It does, though! Bitwarden’s implemented the UI so that it unchecks the 0-9 and !@#^&* options if you set the corresponding minimum number to 0.

@Nail1684

The generator of the mobile Android app includes special characters and numbers even with “minimum 0”. (version 2024.11.7)

@grb

This is not the way that it works in the browser extensions (new or old), Desktop app, or Web Vault.

@kpiris

setting a minimum of 1 character of any type lowers a bit the overall entropy, but IMO is not a bad thing.

List of apps:

• chrome web extension: 0=❌
• firefox extension:
• safari extension:
• windows desktop app: 0=❌
• mac desktop app:
• android app: 0=✅
• ios app:
• web vault: 0=❌
• CLI: 0=✅

3. The ‘Minimum special’ short label shows different characters from what’s generated between the different platforms

The discussion/discrepancy here is that in some apps the ‘label’ for the Minimum special feature checkbox shows different characters. Sometimes !@#^&* other times !@#$%^&*.

It is true that showing a few of the special characters may mislead the user. I was mislead, as it can be seen in OP where i believed only the short character set was used.
Even though i saw $ in the generated password, i ignored it for some reason.

With this in mind, my opinion is that showing just some characters is OK.
My reasoning is as follows:

• the user understands what special characters are by seeing a few of them as example
• in the future the list of characters might change and UI wise it may not make sense to list all of them if they’re too many

There should be the same label for all platforms, to no longer have discrepancies and for the apps to look cohesive.

@grb

The characters are only removed from the option label, not from the pool of characters used for generating the password. That’s a UI design choice.

The option labels are only meant as a shorthand representation of the character class, they are not intended to be replicas of the character set.

@grb’s suggestion seems very good and intuitive. (emphasis mine)

@grb

My personal preference would be for shorter labels (e.g., abc, ABC, 123, !@# — by not displaying these as ranges, we avoid misleading the user into thinking that the label is supposed to represent the full set of characters in each category).

List of apps:

• chrome web extension: !@#^&* - short
• firefox extension:
• safari extension:
• windows desktop app: !@#$%^&* - long
• mac desktop app:
• android app: !@#$%^&* - long
• ios app:
• web vault: !@#$%^&* - long
• CLI:

@dwbit I’m tagging you here as you are able to raise points 2. and 3. to the team.

[kpiris (Kiko Piris)]

@TheBestPessimist

IMO, 0 should be considered a valid option and should not disable the feature because it increases password entropy just a little.

I totally agree with this. But password entropy is a theoretical concept. For it to faithfully reflect the effort an attacker should make to crack a password, both the generator and the attacker should agree on the conditions used to randomly generate the password.

If I generate a random password including lowercase, uppercase, numbers and specials and set the minimum of specials to 0, a password without any special characters could be generated (although unlikely given an enough minimum length).

If I specify a minimum of 1 special character, the generated password will have a slightly lower entropy (because all the possible passwords without special characters are excluded from the list of possibilities).

But for an attacker that doesn’t know the character sets included in the generation and tries to brute force it using only lowercase, uppercase and numbers, the first one (which, from the perspective of the generator, has a higher entropy) will be easier to crack.

To sum up my point:

• a minimum password length is critically important (obviously)
• setting a minimum of 1 character of any type lowers a bit the overall entropy, but IMO is not a bad thing.

PS., bitwarden cli also accepts setting a minimum of 0 numbers or special characters:

kiko@penguin:~ $ bw generate -ulns --minNumber 0 --minSpecial 0 --length 5
&vLrD
kiko@penguin:~ $ bw generate -ulns --minNumber 0 --minSpecial 0 --length 5
XaV3h
kiko@penguin:~ $ bw generate -ulns --minNumber 0 --minSpecial 0 --length 5
R!Yst
kiko@penguin:~ $ bw generate -ulns --minNumber 0 --minSpecial 0 --length 5
PrzaU
kiko@penguin:~ $ bw generate -ulns --minNumber 0 --minSpecial 0 --length 5
WFr7#