|
|
|
|
|
by rotnewson
4735 days ago
|
|
If you can't remember 1 password over 20 characters that you will use a lot with a password manager you probably need to change what kind of passwords you make. Instead of "E=E<4oc^(z&kj6Snm9uy" do something like "The Brown cow jumps over the m00n!". Set the password manager to make you enter the password if you haven't used it for 30 seconds (for a few days so you remember your password). You're using a password manager with a good password that is easy to remember but the you do use the password manager to generate hard to remember passwords like the one above. |
|
Estimates of the entropy of English text place it below 1.5 bits per character. "The brown cow jumps over the moon." would, generously, have about 34 * 1.5 = 51 bits of entropy, plus a few more for the simplistic substitutions - say 70 bits total? This is assuming the sentence was, in fact, chosen uniformly across English sentences, which is obviously not going to be the case (this one being a modification of a line from a nursery rhyme), so in actuality it'll be even worse.
A fully random password of length 20, from characters on a typical keyboard (say 94, it seems to be on mine) would have 20 * lg(94) > 20 * 6.5 = 130 bits. But impossible to remember and a pain to type correctly.
Picking from my /usr/share/dict/words with no restrictions (99171 entries), it would take 70 / lg(99171) = 5 words to be stronger than the sentence and 130 / lg(99171) = 8 words to be stronger than the gibberish, with no substitutions or tweaks, however not all of those passwords could be typed on my keyboard.
Restricting /usr/share/dict/words to those which match (with LANG=C) '^[a-zA-Z]\{1,10\}$' yields 61078 words at about 7.3 bits of entropy per word, so you would get security comparable to the above with 5 (again - aliasing) and 9 words respectively.
Some nine-word passwords generated this way:
The above were generated with LANG=C grep "^[a-zA-Z]\{1,10\}$" /usr/share/dict/words | rl --reselect -c 10 | xargsThis is, obviously, reliant on an assumption that rl produces cryptographic level randomness, which is probably not the case but should certainly be near enough the case for examples (and in any case will be much, much closer to true than any method involving humans - we are very poor sources of cryptographic entropy).