FESCO request to revert password confirmation change in F22

[Björn Persson]

Mike Pinkerton wrote:
> On 7 Mar 2015, at 10:41, Björn Persson wrote:
> > Mike Pinkerton wrote:
> >> On 6 Mar 2015, at 23:49, Adam Williamson wrote:
> >>> On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote:
> >>>> I hope https://xkcd.com/936/ will be among the inputs to that
> >>>> discussion.
> >>>
> >>> I'm fond of noting that pwquality has not yet blacklisted any  
> >>> variant
> >>> of correcthorsebatterystaple. I've been using correcthorse as my  
> >>> stock
> >>> anaconda testing password, since the strength check has been
> >>> enforced...
> >>
> >> It won't stand up to a combinator attack:
> >>
> >> <https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html>
> >
> > It's not entirely clear, but I guess you mean that a two-word
> > combination like "correct horse" won't stand up. That appears to be
> > true. A four-word phrase is an entirely different matter. Each
> > additional word increases the complexity exponentially, so doubling  
> > the
> > number of words squares the number of possible combinations.
> 
> The "combinator" attack that is described in the Ars Technica article  
> that Bruce Schneier quotes in the above link appears to be an attack  
> that tries combinations of multiple words from one or more of the  
> attacker's word lists.  Certainly adding more words to the pass- 
> phrase would make that more difficult.  As I don't know the current  
> state of the art in password cracking, I don't know whether attackers  
> typically limit their attacks to only two words, or extend to three  
> or more words.

Quoting Ars commenter "epixoip", who claims to be one of the reporter's
sources:

| However, it is much more complicated to crack a passhrase comprised of
| several words selected at random, with say a random word generator. I
| have a combinator program that I've written that allows you to combine
| an arbitrary number of wordlists together (similar to combinator.bin in
| hashcat-utils) and accepts an array of characters to use as word
| separators. Sounds awesome, but it's slow as shit and rather
| impractical (which is probably why combinator.bin only accepts two
| lists.) So while there are some flaws with that XKCD comic's logic,
| it's not exactly terrible advice.

http://arstechnica.com/security/2012/08/passwords-under-assault/?comments=1&post=23189016#comment-23189016

> > The catch is that the words must be *randomly* chosen. XKCD doesn't
> > stress that point much, and humans are notoriously bad at choosing
> > randomly. I suspect that many people make up some highly nonrandom
> > four-word passphrase and think they have a "correct horse battery
> > staple"-quality passphrase.
> 
> I don't think randomness matters at all, only whether the words are  
> in the word list(s) used by the attacker.

That means that you assume that the attacker will try to brute-force
the passphrase – try all the possible combinations without any
optimizations. The Ars Technica article that Bruce Schneier quotes and
the second one that he links to both describe at length how the password
crackers analyze patterns in passwords so that they can optimize their
searches by trying other strings that follow the same patterns. It is
naive to assume that they don't analyze patterns in phrases in the same
way. And indeed, "epixoip" says "We're already very good at cracking
passphrases that are derived from quotes, proverbs, verses, lyrics, or
whathaveyou."

To avoid getting cracked by such an optimized search you can choose a
passphrase with no patterns in it. That is a random passphrase. A truly
random passphrase can only be cracked with brute force, so then it's
just a matter of estimating how long it needs to be to make brute force
impractical. Up-to-date knowledge about the cost of processing power and
fairly simple mathematics can yield a good estimate.

If you choose a nonrandom phrase to be able to remember it better, for
example a grammatically correct phrase, then you need to make it much
longer to compensate. Figuring out how much longer it needs to be to
make the crackers give up will be mostly guesswork.

So as you can see, randomness matters immensely.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signatur
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150308/d2e1dd37/attachment.sig>