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

[Nail1684]

Short summary for me, regarding your points @TheBestPessimist :

@TheBestPessimist

1. The entropy

As @grb explained, setting higher minimum numbers reduces the entropy. I would call that “counter-intuitive” and maybe some kind of note/notice would make sense. (I remember, when I had no idea of entropy a few years ago and began with password managers, I thought “more special characters is certainly better…”)

And I think I agree with @kpiris 's additions to the entropy question and it’s practical implications.

@TheBestPessimist

2. Should setting the ‘Minimum’ value to 0 disable the feature altogether or not? […] This should be the same implementation for all platforms, to no longer have discrepancies.

I agree - and whatever implementation - at least it should be consistent between all apps. (UX and so on…)

@TheBestPessimist

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

[grb]

@Neuron5569

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

I wasn’t trying to defend Bitwarden’s design choice regarding the label, I was only trying to convince @Nail1684 that this choice was intentional, not a bug. 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).

 

@kpiris

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

Your point is well taken. It falls under the same category as the following conundrum: what if the random password generator by coincidence happens to generate something like Password123!? In theory, this should have been a very strong password (over 70 bits of entropy), but obviously, it will be very easy to crack. It is this general type of risk that the “minimum character” options is trying to mitigate, although evidently it will never be able to prevent the password generator from producing easily crackable passwords.

Regardless, the entropy reduction that we are discussing is expected to be minimal. For example if we enable two character classes of equal size, and require at least one character from each class, then the entropy reduction for a password containing n characters is given by

ΔE = –log₂(1 – 2^1-n ) ≈ 2^1-n /ln(2) ≈ 2.9/(2ⁿ )

(where the approximation is valid for large n).

The worst-case scenario is for n=2 (as the minimum character constraints are impossible to meet when n=1), for which the exact solution is ΔE = 1 bit. Even for n=5 (the minimum password length allowed by Bitwarden’s generator), the entropy reduction is less than 0.1 bits.

So perhaps the “minimum character” problem is a bit of a tempest in a teacup. I agree that the behavior should be consistent across all apps, though.

I don’t use the mobile apps, but in the non-mobile apps, enabling the A-Z or a-z options also imposes a constraint of a minimum of 1 character from those character classes. I’m wondering how this has been implemented in the mobile apps, however (since the mobile apps do allow the minimum character constraint to be set to 0 for an enabled character class). If you enable A-Z, a-z, and 0-9, then minimize the password length and set the “minimum numbers” option to equal the password length minus 2, does the generator always produce mixed-case passwords, or does it also allow single-case passwords to be produced?

 

@kpiris

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

@kpiris Same question as above. From the examples in your comment, it seems that only mixed-case passwords are generated if -ul is set, but the sample size is small.

[Nail1684]

@grb

I was only trying to convince @Nail1684 that this choice was intentional, not a bug.

I think I will remain in denial a bit longer…

@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).

I didn’t think of that… sounds like a good alternative!

[kpiris (Kiko Piris)]

@grb

If you enable A-Z, a-z, and 0-9, then minimize the password length and set the “minimum numbers” option to equal the password length minus 2, does the generator always produce mixed-case passwords

This seems to be the exact case with Android (non native) and CLI: 3 or 4 dozen passwords generated, all of them with Length-2 numbers, 1 lowercase and 1 uppercase.