[talk] passwd entropy and strength
jpb at jimby.name
Sun Nov 5 23:10:53 EST 2017
* Jan Schaumann <jschauma at netmeister.org> [2017-11-05 14:04]:
> George Rosamond <george at ceetonetechnology.com> wrote:
> > So someone getting some of the passwd really just needs a "Wheel of
> > Fortune" approach to determining a passwd in full.
> > co__ect ho_se batte_y staple
> > "Can I buy an 'r'?"
> It is rather rare that an attacker would have a partial password.
Rare perhaps, but when one or more words, phrases, numbers and or punctuations
are known to be (or could be) present it is extremely helpful. I wrote a
"combinator" to attack just such a problem in trying to recover a
password that I used over 10 years ago.
See the README.txt file at http://www.jimby.name:81/comboleetor_latest/
where you can also download and try out the code. Using this splendid tool,
and hashcat https://hashcat.net/hashcat I was able to recover the password
in less than two hours.
Taking the original post of 'Tr0ub4dor&3' (no space in the xkcd original)
and the comboleetor tool I ran it with the following setup:
echo bNP | perl comboleetor.pl -c > troubador.txt
echo bPN | perl comboleetor.pl -c >> troubador.txt
produced a file of candidate passwords:
$ wc troubador.txt
47040420 47707660 673705670 troubador.&xt
The winning entry was found about half way through the file:
$ grep -n 'Tr0ub4dor&3' troubador.txt
While the real cracking speed depends on the hash type,
it's safe to assume that this password would be found within
[OK, I've gotten *way far out there* on talk at . Apologies!]
> Unlike so frequently portrayed in the movies, brute-force cracking
> doesn't work like picking a lock -- it can't guess the first correct
> character and then move on to the next one. Since the passphrase is
> hashed, you always have to guess the full passphrase, and if it doesn't
> match, you don't know whether or not you got some characters right.
> While it's correct that with a $yourPrimaryLanguage charset passphrase
> you somewhat limit the entropy of the individual characters to the
> printable set, this is usually far outweighed by the length.
> But this is technically true for _any_ restriction you make on a
> password's complexity: if you require, say, 26 char length, and demand
> that at least one must be a number, then one of the chars clearly has
> less entropy than the others. But due to the above (you don't know
> which one, although the first or last ones are more likely candidates),
> you can't trivially reduce your number of guesses other than eliminating
> any guesses that do not contain a digit.
> > Going back to the passwd strength chart, how long does a passwd in
> > 26-universe alphabet have to be to equal on that uses a 95-character
> > ASCII universe?
If I'm reading this right, looks like a 25 characters at 26universe is
roughly equal to 18 characters at 94universe.
Great link. Thanks.
> > The conclusion, to me, is that getting users to use the whole ASCII
> > universe of 95 characters with diversity is an achievable goal
> I don't think it is. People will continue to pick poor (i.e.
> predictable) passwords. Increasing the length overall is the best
> strategy, as reflected in NIST's updated guidelines and across
I agree here. There is (will always be) a percentage of the population
that just doesn't get it or doesn't care. Some people get burned and
learn, other newcomers come in and take their place. I don't think
we will ever get everyone on the same page on this issue.
> Encouraging the use of password managers is the next best bet, but that
> still faces usability and user education hurdles. Excellent for
> environments where you can enforce them (e.g. corporate), but still much
> too high a bar for the general public.
Not too high for techfolk. That's what make this a great list :-)
More information about the talk