I’m moving from KeePass, and there I had the ability to generate passwords with the length I wanted. Here, I’m restricted to lengths from 5 to 128. It would be nice to have that feature here too 
Wow, actually I’m using a lengths of 20 for all my passwords. But some websites restrict password lengths to 15 or 16. 
Bitwarden’s password generator with its 128 characters limit is the highest I have seen among the most popular password managers.
There aren’t many websites that will allow you to register with a 128 character password. I don’t see why you would want, for example, a 256 character password. Currently, a random generated password with a length of around 14 is unbreakable, even if you use all the supercomputers on earth.
2 Likes
One specific feature I’d like to see is lowering the minimum characters by 1 to allow for creation of 4 digit PINs. Currently I suppose you could do 5 digits and then just truncate, but (with my limited understanding of programming) it seems like a quick fix.
@Nik1 Additionally, (assuming no increases in computing power, etc), even after putting all the computers in the world together, a 75 character password with a total of 70 possible symbols (using Bitwarden’s [[email protected]#$%^&*]) could not be brute-force cracked before the heat death of the universe.
At that point it is easier to just crack AES-256 and be done with it.
1 Like
-
More entropy than the encryption you use adds no benefit. AES256 is a 128bit cypher that has no benefit beyond 128bits other than the implementation detail of how it mixes the additional entropy through more rounds. But this can be achieved by a 256bit hash over 128bits of entropy. More than 20 chars of the 96 char space adds no value.
-
“Before the heat death” is an understatement. (edit: 96 is wrong for BW, is 70)First is that it’s actually an alphabet of 96 chars when everything is included, not 70. 96^70 is greater than the entropy of the entire universe. This number is greater than the plank units of energy.
-
Though not practical, larger passwords are technically more able to be attacked. It takes longer to hash them, meaning the unencrypted version of them must be in memory longer for that first step. After the first step, it’s packed down into 256bits for PBKDF2-SHA256. Again, only 256bits of entropy, which is about 40 chars.
-
128bits of strength is the gold standard. 256bit hashes are the gold standard because of birthday attacks in a hash table cuts it down to the square root which is 128bits. Like for ZFS has an option to trust a hash won’t collide. In the case of passwords, because of salting, this is not an issue. 128bits of entropy is considered safe forever, which is 20 chars of the full standard USA keyboard alphabet.
-
From a practicality standpoint, 70bits is perfectly fine for passwords that eventually get changed with a properly configured PBKDF2 to match modern hardware. If you need a password that will always be safe no matter how far in the future, then 128bits. But I know plenty of security experts and pen-testers that use 12 char random passwords because they have a good enough memory and would rather deal with that than a longer passphrase.
-
Even single-case+numeric(36(26+10)) of 20 chars is going to take a Dyson swarm. No earth bound computing system in the next several millennia are going to break that without consuming enough energy to kill most life on earth.
Behold, the power of exponents.
Disclaimer: I do not have a math background in encryption, but I do feel my self competent enough to make generalize statements from an idealized standpoint. Some of the above is a bit simplistic because it assumes ideals and not practical or current implementations. For example, SHA256 might not give perfect 256bit entropy. But there is enough entropy buffer in the discussion to not concern one’s self with minute details that serve no practical purpose beyond being technically correct/wrong.
fyi, if you want to convert an alphabet^chars into bits of entropy: log((alphabet size)^(number of chars))/log(2)
1 Like
Thanks for the interesting discussion! The part about longer passwords being less secure is particularly interesting to me. I know encryption software (e.g. VeraCrypt) has in the past had the issue of potential for interception of data as it gets encrypted in RAM. That’s a good point to further prove that crazy long passwords just aren’t necessary.
As for the character set, I should have clarified that I wasn’t using the full Unicode set. I was basing it off the Bitwarden Password Generator that uses uppercase, lowercase, 0-9, and 8 special characters for a total of 70! Of course using the full set would just go to take your password even further into ridiculously crazy to crack. I definitely agree that for some of my passwords that are e.g. 30 chars it’d be far easier to just break AES!
Thanks for the reply, I enjoyed the read.
Edit to elaborate: I was using log2(70^75) ≈ 460 bits of entropy.
My bad, you are correct about the 70. I guess I was assuming BW used all of the special chars on a keyboard, like ()-=_+[]{}|;’:",./<>? But I assume some of these are impractical/impossible in some situations.
Not that it makes a huge difference. 70^20 = 122.5bits and 96^20 = 131.7 bits. Both are ~128bits.
1 Like
Fun read https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html
From Bruce Schneier, a highly respected cryptologist.
I’d read it all, but to jump to the end
…
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.
And we are currently very far from anything bumping up against the limits of physics, which is why even 128bit is infeasible for us for a long time. And that insatiability is to even brute-force a single 128bit key. Which is why this comic is so funny https://xkcd.com/538/
2 Likes