I hope to have the option of typing my own desired set of special characters. For example, I really dislike ^ but I’m stuck with it if I check for special symbols in the generator. I know I can modify the password thereafter, but I would like to have better control on this.
1 Like
Maybe it would be a good idea to let user define the charset which will be used to generate the random password.
For example, allow user to create and enable several charset (for example numbers, alphabets, capitalized alphabet, symbols, custom charsets).
Then also give user an option to decide how many times the characters in this charset will be appeared in the generated password. For example, maybe some user want 3 numbers, 5 alphabets, 2 capitalized alphabets, 5 characters in “!@#” and 2 characters in “%^*(”. The last two charset could be a custom charset created and configured by user, and user can decide which characters are in those charset.
@InternetNotSafe, you appear to want to take a 17 character password which with the specified character set would have an entropy of 104, and by user interference turn it into a specification with entropy 54. Possible calculation errors notwithstanding, this is a fine example of why human brains should be allowed nowhere near things which should be random. 
I see the purpose of special characters as exploiting such entropy as a website makes available to conforming passwords.
Unless you assume that the characters drawn from each subset will be arranged in blocks and not mixed up (e.g., 371epvghJXE@@!#!*%), then I believe the entropy may be as high as 103 bits*. You do lose some entropy because about half of the randomly generated passwords (drawing from the full 69-charater pool) would fail to meet the required character counts for the individual subsets.
And to be fair, Bitwarden’s current password generator does use a similar method (although the constraints are implemented as a lower bound on the number of characters from each subset).
*This estimate seems to be higher than expected, so I reserve the right to be wrong! At a minimum, the true entropy will have to be lower than 103 bits, because this estimate does not take into account re-arrangements that result in the same password string (e.g., switching the first and second characters in @@!#!). Basically, I took your estimate (17·log₂69) and added Σ(log₂(nPr)) to account for the permutations
I read their specification to be in blocks as written. Otherwise our 103/104 is the same. Randomisation of the block content would move toward the higher figure but removal of constraint of an exact (human-selected) number of characters from each block would also be needed to get there. I always assume the selection strategy is known to an attacker.
With a 17 character password, selecting solely from upper case characters still affords 80, showing the importance of length.
I may have posted something like the following elsewhere here, but this is also an apt location in case it is worth a proposal. For context I use my own password/passphrase generator to get larger word and symbol sets than in Bitwarden. Multiple tests have shown that output from it is statistically random within the symbol space so I am content with it.
Symbols are specified in the following UI elements:
There are two fields, one Include, one Exclude, each with an associated check box. If neither box is checked, my allowable symbol set has 28 elements used freely like alphanumerics. If Exclude is checked then its listed symbols are removed from the 28. If Include is checked then only the set with in the Include field is permitted. This allows relatively simple switching between common website constraints, and complete flexibility.
There is no reason why passwords could not contain spaces. It would increase the entropy and would probably be an addition cheap to develop.
Special Characters are missing from the password generator. At the moment the special characters that the Password Generator generates is:
@ ! # * $ % ^ &
The missing Special Characters that should be added to the password generator to be able to generate is:
< | ( ) . : ; ” - ‘ [ ] { } + = ~ _ - / ? \
I second this request. I would like a tick box to select “Unicode” characters, just like with Kee Pass. I used to use Unicode characters in my passwords all the time. I found the vast majority of web sites work with unicode characters in the password.
I would love to use non-english characters in my passwords to dramatically increase my password’s entropy.
Welcome, @aalvarez1337 to the community.
The downside to using Unicode characters in passwords is that different platforms store them differently in memory. This tends to result in passwords with Unicode characters working where they were created, but failing on other devices.
You would be better served by increasing length than by increasing complexity. As you grow complexity beyond “Case sensitive alphanumeric (a–z, A–Z, 0–9)”, the entropy per symbol grows slowly, but the risk of failure grows quickly.
@aalvarez1337 Welcome to the forum!
I have moved your post into an existing feature request on the same topic.
A post was merged into an existing topic: Filter special characters in generated passwords per login
Dear Bitwarden Support Team,
I am reporting a significant limitation in Bitwarden’s password generator: it repeatedly uses a narrow subset of special characters (!, @, #, $, %, &, *), while ignoring other valid symbols (e.g., :, ;, ?, >, ~, [, ], {, }, +, =, , .). This reduces password entropy and predictability compared to competitors like 1Password.
Evidence from Generated Passwords:
-
Bitwarden Passwords (30-character):
- wTk!J&7%bS%j8ezvhsnCs%WW@Dt%R#
- n9WT6@dvgrq@AhBWCigNt^K9Mze%LE
- WvTQMXETd8$bGX6x$XgGmDb#82oQ$b
- $S9AxcJ9w%944mMYo626Z&v2x@rCG$
- j2K6he%v%fyX@WYa4#DFi#TT6u$Nbr
- j^quPbsBD8aBEwzVYRbf6$7%UqM%ji
- vqn2@xAG$o8U4&!nt@BFH42XPS2Jbs
- gsL6QA2ny6*puxrnZWFGuA&Ny3z#e@
- w@5mbT@zXd@$yscj$qB6n28zrpL8Ja
- #o*3Hkj$tjgvX38f4gzQ72e@Txg&J3
-
1Password Passwords (30-character):
- kdzj29%6)Bx,i9JVRuBEnX6Z1]gd
- st?f0z:a5E:RLJjNE!9PpYwB08x#FV
- ?veBooYrNyJ?Ad#)My-ykD6a80>Y}8
- aX)7,Jt5Q94:Gz1Nn@9BuwVB#Zs=wE
- 6n_BxVmc?h}5.8fsQV0b5^Zh9?1Wdr
- ?ix}F,sLYb%p5L>:qBax7JW4Jer~uU
- mj!Em5B_#znK?4cPu6fo?N0Q5@Yhy,
- j4bnJg.5>hkR3+kL2RF2-w3c~RC*rU
- Rh~xU:Q6A9QKyx)tY:ax#wgKLiey+b
- Hu:ZCEfjami62Y^9G.qo1x%Y-qzB#^
Key Issues:
-
Repetitive Characters: Bitwarden uses only 7 special characters across all examples, with % appearing in 10/10 passwords.
-
Limited Diversity: Missing symbols like :, ?, >, }, =, ~, , ., ), ] which 1Password utilizes.
-
Security Impact: NIST guidelines emphasize character diversity to resist brute-force attacks. Bitwarden’s approach lowers entropy.
Requests for Enhancement:
-
Expand the default special character set to include all printable ASCII symbols (e.g., ~ : ; ? > < = + , . / { } ( ) | \ `).
-
Add a custom character selector in generator settings.
-
Fix algorithmic bias to prevent overusing specific characters (e.g., %).
This change will align Bitwarden with industry standards (NIST SP 800-63) and competitors like 1Password. Thank you for your attention to this security concern.
Platform: Bitwarden Android Mobile App Latest version (03/08/25; 3:19 am Bangladesh Local time)
Sincerely,
MD Habibur Rahman
@iammdhrk Welcome to the forum!
I moved your post into an existing feature request to the same topic.
@iammdhrk Welcome to the forum! I just wanted to correct a misleading claim in your post:
In your examples of Bitwarden passwords, the % character appears only in 5 out of the 10 generated passwords (#1, #2, #4, #5, and #6). Actually, a higher percentage of your example passwords contain the characters $ (7/10) or @ (8/10). There is no “algorithmic bias” or “overuse” of the character % (or other characters — even $ or @) in the way that you are implying.
For an ideal password generator drawing from a pool of 70 characters, the probability that a 30-character password contains a specific character (e.g., %) is close to 35%. However, to observe this average, you need a sample size that is much larger than 10 passwords. For example, if you increase the sample size to 100 passwords, then you should expect to see your chosen character (e.g., %) in 35 ± 12 of the generated passwords (i.e., 23–47 passwords) — with a probability of 95% (95% confidence interval).
If you wish to discuss password generator statistics further, please open a new topic in the Ask the Community category of the forum.
But why you don’t allow more special characters like other password manager? I want to have more special character.
Increasing length turns out to be much more effective at increasing entropy than increasing complexity. Even NIST is no longer a fan (for going on 10 years now) of complexity. Adding just a few extra characters will make up for the entropy loss by using a more reliable character set.
Hmmm… but doesn’t that count for “memorized secrets”, as the title in your link says? – For passwords stored in the password manager, where I don’t have to memorize the password, complexity is not a problem. And there are still accounts/services out there with a very limited length for passwords. – So, in general, I think the request for an expanded pool of characters does make sense.
2 Likes
Unless password managers are required for all users of the service, then a password is still considered to be a “memorized secret”. The official definition is as follows:
A type of authenticator comprised of a character string intended to be memorized or memorable by the subscriber, permitting the subscriber to demonstrate something they know as part of an authentication process.
Section 5.1.1 of Special Publication 800-63B further explains that “memorized secret” is just the formal term for what is commonly known as a “password”:
A Memorized Secret authenticator — commonly referred to as a password or, if numeric, a PIN — is a secret value intended to be chosen and memorized by the user. Memorized secrets need to be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value. A memorized secret is something you know.
And before you ask, in the above excerpts from the NIST standard, the word “authenticator” is defined as follows:
Something the claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity. In previous editions of SP 800-63, this was referred to as a token.
1 Like