I completely agree with this, and I note the following:
-
The only thing that makes sense is for a meter to display the password entropy and/or the number of permutations possible. As you’ve noted, any judgements as to “quality”, “strength”, or cracking time/cost depend on assumptions with a validity that is ephemeral, and would therefore be irresponsible to display to a user.
-
To display a “time to crack” estimate, Bitwarden would either have to require the user to explicitly select their assumed hashing rate (e.g., 106 H/s), or they would have to pull benchmark numbers from a source that is periodically updated (even then, some assumptions about the hash algorithm and number/type of processors used would have to be made). Furthermore the “time to crack” value would have to be shown with a disclaimer, such as “100 years (using a single RTX 4090 GPU, assuming MD5 hashing)”.
-
It is essential that any password entropy calculator be completely disabled when a user enters their own password, or makes modifications to a generated password. There is no valid method to compute password strength based on analysis of a specific password exemplar, so it would be irresponsible and misleading to attempt to do so. The entropy estimate should be based only on the options that have been selected in the generator.
-
Even for generated passwords, the effective entropy is reduced (and becomes impossible to calculate) if a user re-generates the password/passphrase (so that they can cherry-pick one that appeals to them). Thus, the entropy meter value should be cleared if the user re-generates a password without having first changed at least one setting in the generator configuration, or selected/copied the previously generated password.