Avoid Arbitrary Length Restrictions in Generator

Feature Requests Password Manager
,
1

Background:

As of Desktop and Web Vault version 2024.11.0 (as well as version 2024.11.999 of the redesigned browser extension), the password generator raises the lower limit for passphrase length from 3 words to 6 words (see PR 11675) — corresponding to 78 bits of entropy. Furthermore, for the generation of passwords (random character strings), there currently is a hard limit of 5 characters — corresponding to 15–29 bits of entropy (depending on the character sets included).

Proposed Changes:

This Feature Request proposes two related changes:

  1. The hard lower bound for generated passphrases and passwords shall be either eliminated or significantly lowered (e.g., to 2 words and 4 characters, respectively).

  2. If any hard length restrictions for generation of random secrets are enforced (especially any lower bounds that are more restrictive than those suggested in Item #1 above), then those restrictions shall be consistent for generation of passwords and passphrases (i.e., the minimum and maximum entropies shall match).

Use-Cases:

There are very legitimate scenarios under which a passphrase shorter than 6 words (or a password shorter than 5 characters) provides proper security for the application at hand. For example, the Bitwarden vault master password itself does not need to have more than 50 bits of entropy to provide sufficient protection against plausible brute-force attack scenarios (and PINs used for unlocking should have even lower entropy — perhaps as low as 30 bits). Another example is PINs used for user verification on Yubikeys — as illustrated here, even a 13-bit PIN provides reasonable protection against a brute-force attack, and anything higher than 43 bits seems to be overkill.

There are similar use-cases in which passphrases with entropy lower than 78 bits are perfectly suited for the application. In addition, 6-word passphrases are more difficult to memorize, take longer to type, and are much more likely to run afoul of websites’ maximum password length restrictions (on average, a 6-word passphrase will consist of 47 characters).

Discussion:

The range of allowed passphrase lengths is now 6–20 words, corresponding to an entropy range 78–266 bits. At the same time, the password length restrictions are 5–128 characters, which corresponds to an entropy range 15–785 bits. In my opinion, it makes absolutely no sense why the allowed entropy range for generated passwords should be 4 times larger than the allowed entropy range for generated passphrases.

My recommendation would be to not impose any hard minimum length restrictions in the generators, giving users the flexibility to generate random secrets for any purpose. Instead of hard limits, it would be more appropriate to implement default length settings (e.g., 12 characters and 6 words, respectively) to guide users towards making more secure choices.

As a final thought, although this Feature Request focuses primarily on the lower bounds, some consideration could also be given to the upper bounds of the password/passphrase lengths produced by the generator. For services that hash passwords into a 256-bit hash, it could be argued that the maximum reasonable length for the generator should be 20 words in generated passphrases or 86 characters in generated passwords. However, it is better to give the users flexibility, because it is not a given that the generated secret will be stored as a 256-bit hash (or used in 256-bit encryption); it should be noted that the password generator currently allows up to 128 characters, corresponding to 384–785 bits of entropy (clearly far beyond 256 bits). The password fields in Bitwarden login items can store approximately 3500 characters; this would be able to accommodate passphrases as long as 437 words (5660 bits of entropy if a number is included) — a password with matching entropy would have 923–1887 characters.

23 Likes
2

If one does eliminate hard minimums, the user needs a way to understand the strength of the password/phrase being generated.

And perhaps display a warning if the generated pass-thing would be less strong than recommended by some authority (e.g. NIST - 8 printable ASCII characters.)

4 Likes
3

Perhaps, although that approach is fraught with its own perils, as I have previously explained in the relevant feature request thread (and if you wish to further discuss issues surrounding strength indicators, I would be happy to do so in that thread).

An alternative approach to “protect the user from themselves” would be to make available a user option (under Settings, not in the Generator UI itself) to “Allow generation of passwords/passphrases with fewer than X bits of entropy” — the value of X could either be fixed (in which case the user would have the option to enable the option), or adjustable (allowing the user to set their own lower bound).

2 Likes
4

Some comments in relation to this request, for which I have voted.

There are many instances where it suffices to have a deterrent-level pass phrase, 2-3 words, rather than highly secure, yet it makes sense to keep these in Bitwarden as an aide-memoire. Examples include access to home equipment or even to sites of low data value. Yes, one could use a short password instead but with less hope of casual memorisation and, why should that option be compelled?

Secondly, the inconsistency is insupportable.

Given this is a function of the generator, not of storage and use, the likely outcome is a reduction in security for a broad swathe of users, because they will either “generate” their own non-random pass phrase or risk using an internet service to get a better one, for anything up to a fully sufficient five words.

Presuming some rationale behind the minimum pass phrase advice, why not provide the Settings option?

3 Likes
5

I like having profile level defaults and I like guidance. I don’t like mandates.

Even more I’d like the ability to restrict the total length of the passphrase at generation time to meet requirements, and have the program use a number of smaller words to build the passphrase to compensate.

1 Like
6

Please let the user choose what they consider safe.

At the moment I have simply stopped using Bitwarden’s password generator feature and am using an online generator.

2 Likes
7

I must say I share that consent - and also because of other reasons which are off-topic here and relate to other feature requests (like including more special characters and at the same time being able to exclude single characters). Before I came to Bitwarden I used KeePassXC - and I still like that generator a lot more. So, maybe also a bit off-topic here, but I would suggest to you, using the (offline) generator of KeePassXC instead of an online generator. :wink: (KeePassXC is free and works on all platforms - except mobile - so easy to use)

8

I disagree with the restrictions that are placed on generation of passphrases or passwords. There are too many poorly written and managed apps, websites, and software out there that make 6 words a hard limit to work with. Some sort of warning or guidance for low entropy is a good idea, but the 6 word limit is quite annoying.

6 Likes
9

I assumed that the 6 words was a bug in my extension instead is intentional behaviour… this is ridiculous

3 Likes
10

This is bad and I created a community account specifically to say it’s bad. Please revert.

2 Likes
11

@Unadilla @toddiespatties et al.: The 6-word-minimum is already being reverted. E.g. see here Releases · bitwarden/clients · GitHub the last releases the last hours (Web & CLI 2024.11.1 and Desktop 2024.11.2)…

PS: And I think, the browser extension version 2024.11.2 should also contain that fix… (it’s not in the release notes, but if you compare the 2024.11.2 with the 2024.11.0, you see that the “revert passphrase lower limit”-PR is implemented in the browser extension 2024.11.2)

2 Likes
12

Just wanted to say thank you for the quick response. I can now use the generator normally again and understand the reasoning to require lengthier passwords, but my use case is for end user temporary passwords that are generated and then destroyed when a user is forced to change their password on first login.

BW-cli makes this a breeze to do in Raycast. I can’t expect end users to type in lengthy passwords like this and passwords of that length will likely not work on all systems, so three word passwords are fine for this situation.

2 Likes
13

I signed up to vote on this issue. but I apparently dont get votes as a new account.

1 Like
14

For the love of god PLEASE remove this restriction. The built in passphrase generator was one of my favorite features up until a few days ago when I noticed I wasn’t ALLOWED to make a password that would fit into a website’s max length.

Even putting aside the legitimate use-cases for a shorter password (i.e. most websites enforcing their own arbitrary MAX length limits on passwords, which is dumb in its own right), developers need to stop treating users like children and let them make their own decisions. This is wildly overreaching. If someone decides to make a one word password and gets hacked, that’s their problem. Bitwarden is not a security advisor, it’s a password manager. I see no reason to police users on this matter.

4 Likes
15

First, I would like to extend a welcome to new forum members @VultUx, @toddiespatties, @mursec, and @Plathix!

Second, I should clarify that the recent change of the passphrase hard limit from 3 words to 6 words minimum has already been reverted, and it is again possible to generate passphrases with 3–5 words in version 2024.11.2 (Firefox users may still be waiting for Mozilla to release the new update, though).

Third, I would like to say that even though I am the OP of this feature request, I am surprised that so many users have been generating passphrases with sufficient regularity that this temporary code change caused major hardship! Thus, I would like to offer the following Public Service Announcement:

:warning: Passphrases should only be used for secrets that have to be memorized, typed, or spoken!

Users of a password manager obviously do not need to memorize any passwords other than their vault master password (and possibly one or two others), so this means that passphrase generation should mostly be limited to accounts for which you may have to verbally communicate a password (e.g., a WiFi password), or passwords that need to be manually typed (e.g., to unlock resources on devices that do not have a Bitwarden app or web browser). I would think that these scenarios are the exception rather than the rule for most users, so the need to use the passphrase generator should be rare for most Bitwarden users.

The reason why passphrases should not be used routinely, and certainly never for any passwords that will be stored in Bitwarden and autofilled into website login forms, is that to have the same strength as a password consisting of random characters, the passphrase length (in characters) would have to be 4× as long as the random-character password of equivalent strength. For example, the 3-word passphrase residual-passerby-module has 24 characters, and is therefore only as strong as a password consisting of 6 random characters (6tBJ!4). If you wouldn’t entrust your account security to a 6-character password, then you should not be using a 3-word passphrase for that account.

Here’s another example: Suppose that a website imposes a 20-character limit for the login password. If you wish to use a 3-word passphrase, you will probably have to generate a half-dozen passphrases before you get one that fits, because out of the 470 billion possible passphrases consisting of 3 words, there are only 85 billion word permutations with a total passphrase length of 20 characters or less. Thus, on average, an attacker would only have to try 43 billion guesses before finding the correct passphrase. In an offline attack against a stolen hash table, it would take at most a few days for a brute-force attack to succeed (assuming bcrypt hashing).

In contrast, if you use a random-character password consisting of 20 characters, an attacker would have to test 4×1036 guesses, on average, to crack the password by brute force. The time required to crack such a random-character password would be over a trillion times the age of the universe.

Thus, you’re trading a significant amount of security for the benefit of having a password that can be more easily memorized, spoken, or typed. If you never plan to memorize, speak, or type the password in question, then you have wasted all of that security for nothing by generating a passphrase instead of a password.

4 Likes
16

Same thoughts exactly!

17

If the website supports the necessary length, where is the harm with me using a 6-word passphrase instead of a 12 character password?

I don’t see why one would say “passphrases bad” instead of “passphrases need to be long too” and perhaps follow up with " A 12 character password is equally good as a 6 word passphrase".

18

Obviously @grb will answer for himself, but just my two immediate thoughts on that:

  1. It is not necessary to use passphrases, when you don’t have to memorize or (frequently) type or speak (like @grb ) expressed it. Passphrases don’t have any advantage in that scenario, so passwords would be “better”, because they are inherently stronger (if we speak about comparable lengths - and given, all criteria for good passwords and passphrases are met, like random etc.)
  2. I see the risk of possibly expose oneself if there was a certain pattern that many, most or all of one’s passwords share, like “every credential I have is a 4-word-passphrase” (just an example). If one or more of my credentials got leaked, then a hacker could focus on just 4-word-passphrases and exclude many other options for “brute forcing” etc. (BTW, the same may not completely be different for passwords… and that’s why I - at least - like to choose different lenghts in my passwords, so that the pattern is not completely transparent)
1 Like
19

@DenBesten Yes, the guidance in my “PSA” are could be softened for cases in which the service does not have password length restrictions (or even when limits exist but limits allow for passwords with at least 60 characters).

However, a PSA is directed at the “public”, which will generally not be familiar with differing entropy calculation methods for passwords and passphrases, and can therefore not be relied upon to determine the required length of a passphrase. Moreover, the general “public” is unlikely to be able to determine the maximum allowable password length when it has not been clearly posted (e.g., by inspecting the HTML code of the password <input> field, which I routinely do myself when creating new accounts). And this does not even touch on problems that arise when websites set a password length limit on the account registration form, but truncate submitted passwords to a lower length limit on their login form, or websites that have different password length restrictions (for the same account) on mobile vs. non-mobile login forms.

Considering the computing technology available today, and with no knowledge of hashing algorithms used by a service, it is necessary to use a password with entropy in the range 70–90 bits (or 78–99 bits, per a selection of “authoritative” sources that you’ve quoted elsewhere). Thus, a passphrase would have to have 6—8 words to be secure; this would (on average) give a character count in the range 47–63 characters, and could be as high as 80 characters.

My intent was to provide a simple rule of thumb that would improve the security of users who do not wish to learn about entropy calculation and do testing of each website’s implementation of password length limits. For such users, it would be inappropriate to routinely generate passphrases, because they would be at high risk of either running into problems (including account lock-out) caused by length restrictions, or using passwords (passphrases) with insufficient entropy.

From the amount of user pushback against the recently implemented 6-word limit, it is clear to me that many Bitwarden users are routinely generating passphrases that are too short to provide adequate security. My PSA was directed at those users, not at you.

3 Likes
20

It seems, perhaps, strongly recommending Initial Caps and a 1Random number be included in shorter passphrases would sufficiently solve the problem. Perhaps a secondary check on a generated password before presenting it to the user would be to insure it’s of sufficient length? blue-mud-cake vs. satiable-thicken-ribbon for example. Hungrily-Catnap6-Rimless