On Tue, Mar 10, 2015 at 5:38 PM, Björn Persson <Bjorn@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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
