[talk] passwd entropy and strength

[Jim B.]

* 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:

  blocks.txt
    troubador
    trombone

  numbers.txt
    %d
    1-10


  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  
    28512753:Tr0ub4dor&3

While the real cracking speed depends on the hash type,
it's safe to assume that this password would be found within
an hour.

[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?
> 
> https://i.imgur.com/gfYw57t.png

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
> experts.

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 :-)

> 
> -Jan
> 

Jim B.