Anaconda 22.17+ enforces "good" passwords

[Chris Murphy]

On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač <mitr at redhat.com> wrote:
> Hello,
>> I'm noticing that Fedora depends on the user passworld, plus a salt,
>> and the glibc sha512-crypt.c default of 5000 rounds through SHA512, to
>> create the hash found in /etc/shadow.
>>
>> - Could the security team provide some guidance on the work needed,
>> the time frame required, to increase the number of rounds? And also
>> how many rounds should it be set to? I think this can be done by
>> modifying /etc/pam.d/passwd. And if there's consensus on this, or any
>> other alternative, if it could be noted in this FESCo ticket, I think
>> that would be helpful. https://fedorahosted.org/fesco/ticket/1412
>
> I really don’t see the number of rounds having any effect on that ticket.  The anaconda policy change was AFAICT primarily driven by wanting to make ssh attacks more difficult, and making offline attacks more difficult is not relevant at all.
>
> Sure, increasing the number of iterations would also slow down the ssh guessing process, but that would hardly be noticeable.  The CPU time needed to perform a password check is hardly a binding constraint in the SSH bruteforcing scenario: assuming a round-trip time of ~10 ms, and therefore session setup time on the order of 50 ms, the current time to check a password (a few ms) is almost invisible in the whole process, and even a plausible iteration increase to require 50 ms per password check would at best halve the number of possible attempts.  OTOH real rate-limiting (to, say, 2 guesses per second) could easily decrease the guessing rate by thousands or higher multiples.

OK so to do the slow down via more SHA512 iterations is essentially
pointless. And to make it actually slow things down meaningfully
necessitates adding some kind of KDF (like scrypt or PBKDF2)
supporting to the authentication path. Are those correct?



>> The point is, there should be a qualified alternative to the password
>> policy change that Anaconda has already implemented; and also as a
>> short term stop gap to the request by Anaconda that FESCo should come
>> up with a distribution wide password quality policy.
>
> Yes, such a policy would be good; I still think getting a good policy will involve writing significant amount of new code, not just tweaking the configuration options that have been available for the past $many years.

Right. In that category of new code, is a guideline (instructions)
integrated into each UI that's going to significantly increase
enforced higher quality passwords. But this work is omitted from the
current installer behavior, and likewise doesn't exist in Gnome Users
or in Gnome-Initial-Setup or in the KDE, Mate, etc equivalents.
Instead the proposal expects the user to either iterate, or magically
choose a sufficiently long or strong enough password as their first
choice. The latter might be a majority case, I don't know, hopefully
that's true. But instances of the former will at least be in the
significant minority, and that's likely to result in enough resistance
to warrant an alternative plan.


-- 
Chris Murphy