Indeed. The Bitwarden one does not look as pretty as the Keypass one, but it produces similar results.
Generated passwords? That would be easy to calculate because they’re random. (alphabet size)^(number of characters). If you’re talking about a human created password, that is more difficult because they’re not actually random and the alphabet is unknown.
Any news regarding the password strength meter in Bitwarden? Would be great to know if something is in the pipeline…
i would like to have this feature in bitwarden too
There is a weak password report under the premium features that might be used as a workaround.
But it is a shame this is a premium feature as password strength checking is IMHO a core feature of a password manager.
And having this per entry like KeePass does makes it more noticeable.
+1 for this feature.
It would be good to include the password strength testing tool within the Tools section with the Generator for all BW bundles. I’m more comfortable testing a password after I’m logged in to BW. If I’m missing something, let me know.
Thx
Would it be possible to provide an information in the password/passphrase generator how many characters there are in the selected character sets or how many words there are in the passphrase dictionary, and how many bits is the resulting password/passphrase complexity?
@Mihails Welcome to the forum!
Your feature request is reasonable (and may have already been proposed previously — if I find an equivalent thread, I will merge yours*); however, if you (or anyone else reading this) simply wants the numbers, they are:
| Token Pool | Number of Tokens | Entropy |
|---|---|---|
| Passphrase Words | 7776 | 12.92 bits/token |
| Uppercase Letters (all) | 26 | 4.70 bits/token |
| Lowercase Letters (all) | 26 | 4.70 bits/token |
| Numbers (all) | 10 | 3.32 bits/token |
| Uppercase Letters (unambiguous) | 24 | 4.58 bits/token |
| Lowercase Letters (unambiguous) | 25 | 4.64 bits/token |
| Numbers (unambiguous) | 8 | 3.00 bits/token |
| Special Characters | 8 | 3.00 bits/token |
*Edit: I merged your request into this old feature request thread, which is essentially asking for the same thing. Over the years, others have also requested this type of functionality, but at the time, mods saw fit to merge all feature requests related to the Password Generator into a single “mega-thread” (and you will recognize your suggestion as the final bullet point in OP’s top post there):
More Password Generator Enhancements (Comprehensive List)
Personally, I think it was a mistake to merge all of those distinct requests, since it confounds discussion and voting (i.e., users may agree with some of the proposed features, but disagree with others). Hopefully, your Feature Request can remain distinct from the mega-thread.
Thanks, grb.
I also think that the rules “Minimum numbers” and “Minimum special” reduce entropy, so the meter should take this into account. However, if the generated password doesn’t contain these symbols, it could be cracked by brute force over a smaller character set, so entropy would be much lower. E.g. for a 14 character long A-Z, a-z, 0-9 password there are 2^83.359 possible combinations, but for a A-Z, a-z password - 2^79.806 combinations, so that for a A-Z, a-z, 0-9 password with at least one digit there are just 2^83.230 combinations. While “Minimum numbers”/“Minimum special” is set to 1, the difference is very small, but if it’s set to a larger value, it could be quite large.
Good point about the minimum character requirements.
If I recall correctly, the way that these minimum character requirements are implemented in Bitwarden is to first select the required minimum special/numerical characters, and to then randomly substitute these into a random password that was created without the minimum character requirements. This results in a slightly different entropy, but one that is harder to calculate.
The iOS app Strongbox has a fantastic password strength meter built-in. And it doesn’t trip on things like 123456abcde!@#. If you can, I recommend you check it out. For any password you enter, it provides an estimate of how long it would take a wicked fast super computer to crack it. Really cool.
With rapid advances in computing technology, as well as recent and projected advances in quantum computing, providing an estimate as to how long it will take to crack a password can be misleading and is what is often called “security theatre”.
If someone enters a password, and Bitwarden claims their password will take an estimated 10 years to crack, what will their satisfaction be when Bitwarden has to update the model in a short while and changes that estimate to 6 months?
Such calculations also ignore one the most critical factors when making such estimates: the perceived threat source. If a child is worried about someone finding their iPhone and guessing their password, that’s a very different threat assessment than the CEO of an energy infrastructure company concerned about industrial espionage or state actors. The resources available to those that may want to compromise the password in those cases are vastly different.
I didn’t follow the entire discussion here, but what you (@bit) wrote… that is why I like “(estimated) entropy” as a measure more than estimations about possible cracking time. Though the recommended entropy also will change with advancements in computing power. But “change” itself can’t be abolished 
and some method of measure is needed. But on the other hand, entropy is more abstract than an estimated cracking time, so possibly both measures would be good to have and/or the “normal users” have to be more educated about entropy… 
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.
Hashing rate can be quite high if, for example, there is a China government funded attack or tens of millions devices botnet attack.
Also, calculated cracking time 50 years means that there is a 50% probability that it will be cracked in 50 years and 1% probability that it will be cracked in 1 year. I think for many people even 1% probability that it will be cracked in 50 years would be too high.
Anybody who is following this thread (@Mihails, @bit, others), be sure to provide feedback on the user research survey that Bitwarden is currently conducting (“Do you use password strength indicators? Complete this survey!”).
In my opinion, which I have voiced (both in my survey responses, and in comments on the linked User Research thread), the approach that they are contemplating is severely misguided. Evidently, they are using some calculation based on user-entered characters, and translating the result into cute phrases like “Strong passwords are unique and have a mix of characters” or “Nice, that’s a good password”… The purpose of the survey appears to be primarily to confirm whether the feedback provided is sufficiently “encouraging” to the user, not to question the overall validity and usefulness of the tool.
As already discussed in comments above, this type of calculator is by necessity based on a host of invalid assumptions, and will produce results that do more harm than good.
It would be awesome to see the entropy of a password created in the password generator. Along with seeing how many characters the password is and how many years it would take to hack. Lastly this feature should extend to created logins and also when a hidden field is created the user can enable the hidden field to act like a password. Which would then show the entropy and how strong the hidden field is.
@anon54069917 I moved your feature request into this existing feature request thread.
With regards to your suggestion to estimate the time to crack, please read the discussion above, starting with this comment and the responses.
A given password does not have any entropy as such. A generator of given definition has an entropy per symbol. The rest is just count, a multiplier of symbols and even so, the generator is capable of generating a password which happens to be in a range commonly tested by hackers especially where the symbol count is ‘insufficient’. Post facto entropy measurement is very unstable ground.