Such manipulations are largely ineffective. The capitalization, being a non-random decision, adds zero entropy (and would add only 1 bit of entropy if the decision to capitalize was made randomly). Adding a random digit to a 3-word passphrase provides less than 5 bits of additional entropy. So the proposed mitigation would change the entropy of a 3-word passphrase from 39 bits to at most 45 bits. This level of entropy is not sufficiently high for situations in which a 6-word passphrase (78 bits of entropy) would be called for.
For perspective, a 45-bit passphrase is over 8 billion times easier to crack than a 78-bit passphrase (but it is only 60Ă harder to crack than the original 3-word passphrase without the added number and capitalization).
My use case for passphrases is Android apps. For some reason too many android devs really love to reinvent the wheel and use custom fields that are very fancy but they donât behave like normal password fields so:
Theyâre not detected by any password manager
Because they hate the user you canât even paste
You need to type again the password for confirmation and they disabled copy/paste
The internal fields name is something stupid and the password manager autofills them as user/user
So, for those I need to type with the soft keyboard and I use passphrases. Thereâs no harm if for âWebtoonâ the passphrase that I chose is as safe as a 6 digits password, nobody is going to brute force that.
Now, if itâs something like an encrypted document with vital information where the attacker can use offline methods with GPU acceleration and rainbow tables, then a long password is much better
The problem is, when creating a web or app password you often donât know if it is going to be compatible with bitwarden, or if you are going to have to type it in, until you try it, which you canât do until after creating the account. I default to passphrases just in case I will need to type it. And 99% of things requiring a sign up donât have anything worth hacking in them anyway.
While I understand passphrases are overall less secure than a password, as many other users mentioned, there are many reasons why a shorter passphrase would be preferred/required in certain scenarios and the lower security is acceptable.
Regardless, I donât believe that any limitations of this nature should be forced on a user. Itâs bad enough dealing with arbitrary password limitations imposed by websites and apps.
Iâm glad to see that this change is already being reverted (still waiting for my Firefox extension to update). I actually wouldnât mind even more customization for the generator, though I donât know yet what that would look like.
I would really advise against this. The number of sites in which you truly cannot autofill the login forms is small â most autofill issues can be solved using linked custom fields, and for those few where custom fields donât help, credentials can be transferred via drag-and-drop or copy-and-paste. With extremely rare exceptions, the âneed to manually typeâ scenario only applies to devices where you cannot install a Bitwarden app or browser extension (e.g., a TV).
Setting up linked custom fields just to increase the security on a web page I may never visit again and has no personal info saved doesnât seem like a good use of time to me.
Yes, but you said you were generating passphrases by âdefaultâ, which implies that you are using this approach routinely, on (almost) all accounts. That is what I was advising against.