FESCO request to revert password confirmation change in F22

[Chris Murphy]

On Tue, Mar 10, 2015 at 5:38 PM, Björn Persson <Bjorn at rombobjörn.se> wrote:

> In the hope of clearing up any
> misunderstandings I'll make these statements:

Thanks for the clarifications. My own clarification is that what I
wrote is directed "at large", not only to you personally. Usage of
"you" was intended to be plural/generic.


> · The assertion that users in general know what a good password is is
> not a valid argument, because it's so obviously false that it's plain
> ridiculous.

I'm uncertain how these things are even graded. There's a wide
assortment of opinions on the subject, so I'm not convinced the
problem is well enough understood by experts let alone users in
general. What probability of a successful brute force attack
distinguishes between good and weak passwords?

Enough of this is sufficiently complicated by features such as rate
limiting, attempt limits, reducing attack surface in various ways,
that the same password may be sufficiently good in one case but not
another. And users in general have no way of knowing or assessing such
things. To what degree are they simply lucky because they're never or
only very lightly and rarely attacked? There are many distortions
here.

> · A policy that would permit "Tr0ub4dor&3" because it contains upper
> case, lower case, digits and symbols, but forbid "correct horse battery
> staple" because it's all lower case, would be counterproductive and a
> terrible mistake.

Sure. Literally those passwords are disqualified because they're
published. But as far as password types go, any leetspeak encoded
dictionary word or words is suboptimal. It's a question of attack
efficiency at what point in an attack a 3-4 word passphrase is guessed
relative to leetspeak words, I have no idea if efficiency algorithms
figure that leetspeak is more or less likely to be chosen by a human
user thinking it meaningfully obfuscates attacks.

The actual intended Anaconda password policy is unclear, not least of
which is it's not stated in the UI. The change log suggests an 8
character passphrase with some complexity is necessary, however in
practice it requires 10+ characters with some complexity. Completely
random 8 and 9 character passwords are rejected.

Efficiency wise, I'd expect passwords of 8 characters with some
complexity to be guessed before 3-4 word passphrases. However, I'd
expect 3-4 word passphrases guessed before password of 10-12
characters with some complexity. And in any case efficiency wise I
think without any other mitigating factors like rate and attempt
limiting, the time frame for a successful attack is sufficiently short
for all of these that the password quality change proposed lacks
efficacy and doesn't solve the problem it's intended to solve, and and
a high UX cost.

So I'd still say, if Fedora really wants to go down the road of being
a policy enforcer (uncertain), if it really thinks it has the
political capital with the community that this sort of might does make
right, I'd say they're better off using it in a bold meaningful
fashion rather than one that's next to meaningless. And that'd mean
disallowing anything less than 25 characters. Give or take.


-- 
Chris Murphy