@Jas7 Welcome to the forum!
I moved your post into an existing feature request on the same topic.
1 Like
A hacker trying to crack a password doesn’t see the password initially, they see an encrypted value. That value, showing a repeated character, tells the hacker that these two characters are the same reducing the amount of attempts required to hack the password. Especially if they crack that character. Therefore each character being unique makes the password more secure not less.
With the character repeating more that 2 times is even less secure.
Unfortunately, I’ve still come across some sites that only allow an 8 character password. It’s way outdated but what can you do but complain to the site developer.
I’ve used 12 characters, I could go up to 16 but reading the articles you posted, I feel better going to 18-20. Unfortunately, those passwords can’t be remembered, only copied from BitWarden and “pasted” into the web site logon page.
Actually, they should see some kind of hash – and hashes are one-way functions. Two same consecutive characters won’t show as two same consecutive characters in the hash. It doesn’t work like that. (and that would actually be pretty dangerous)
I think there are different ways to calculate entropy – and I would agree: theoretically (and for the sake of the argument, I take it to the extreme now), if all characters were the same (i.e. one character repeats for let’s say 40 times), that would be problematic. E.g. KeePassXC’s generator includes “pattern analysis” in it’s entropy calculation:
But, such a password is very unlikely to be a result of randomness…
And so, under normal circumstances, I certainly go with @grb:
Well, I thought we were using password managers to not have to remember most of our passwords?! A Bitwarden login item doesn’t care about the kind of password it stores…
And most of the time I would use Bitwarden’s autofill options – and avoid copy & paste as much as I can.
As @Nail1684 already explained, you’ve misunderstood how passwords are stored. They are stored as “hashes”, which are scrambled versions of the password string; the full password string is hashed at the same time — hashing is not character-by-character. You can test this using a hash generator. For example, below are the hashes of various strings containing a repeated character (in this example, the hashing algorithm is “MD5”, but other hashing algorithms work in a similar way):
| Password String | MD5 Hash |
|---|---|
A |
7fc56270e7a70fa81a5935b72eacbe29 |
AA |
3b98e2dffc6cb06a89dcb0d5c60a0206 |
AAA |
e1faffb3e614e6c2fba74296962386b7 |
AAAA |
098890dde069e9abad63f19a0d9e1f32 |
As you can see, it is impossible to tell from the stored password hash whether it contains repeated characters, and if so, how many times the character is repeated.
On the other hand there is a significant drawback to imposing unnecessary restrictions on the password generation. If you forbid any character from being repeated, then the password strength is greatly reduced, because you make it easier to guess your password (by eliminating potential candidates from the pool of passwords that the attacker needs to test). For example, for Bitwarden’s full character set (70 characters), if you randomly generate an 8-character password (e.g., 7g%T$7#Z), then there are over 576 trillion possible password strings. However, if you stipulate that no character can be repeated, then there are fewer than 381 trillion possible password strings. Thus, by disqualifying 34% of the random password strings, you’ve reduced the brute-force cracking time to 66% of what it would have been if you permitted repeated characters. Put another way, without restrictions on repeated characters, the 8-character password becomes 50% stronger.
If you generate a random 18-character string as a password, then the password becomes almost 11× easier to crack if you disqualify any passwords that have repeated characters. For a 20-character password, forbidding repeated characters makes the password over 20× easier to guess.
1 Like
Here is an example to help understand how limiting choice hurts.
Imagine we are generating a 6 digit password. For the first position, you can pick one of 10 numbers. For the second, you can also pick from 10 numbers. Same for the third, fourth, fifth and sixth. In total, the number of possible passwords is 1,000,000 ( = 10 * 10 * 10 * 10 * 10 * 10 ). And, the odds of me guessing your password on the first guess is the inverse of that, one-in-a-million.
Now, if we implement a rule that digits can not be reused, you can select one of 10 numbers for the first position, but you can only select one of 9 numbers for the second position and one of 8 for the third, etc.. In total, you have only 151,200 ( = 10 * 9 * 8 * 7 * 6 * 5 ) possible passwords.
And, don’t get too hung up on complexity. One can exchange length for complexity. Turns out when randomly generated, these have the same approximate strength:
WK\ZpM8;8 characters selected from all 95 printing ASCII characters.QB9pYTxMa9 characters, selected from upper, lower and digitskhljuzedwyua12 lowercase lettershardener demise oversweet explain4 diceware words (aka passphrase)
Use which ever approach you prefer. Me, I use passphrases if I anticipate typing it (e.g. a master password) and upper/lower/digit if I will be using autofill. I only add complexity if the website demands it (due to risk of problems).