Anaconda 22.17+ enforces "good" passwords

[Miloslav Trmač]

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.

(And, in general, strong protection against off-line attacks seems fairly low on the list of things that are worth improving.  If an attacker collects any sizable number of passwords, the goal is not to crack them all but to just find a few weak passwords, and for that the limiting factor is the position of the weakest password on the top-N list (is it 100 guesses? 1000 guesses?  Very likely not millions) rather than time needed for brute-forcing password hashes of any complexity.)

*shrug* To get back on topic, the usual UI guidelines point towards targeting a maximum budget on the order of 50 ms for changing or verifying a single password.  And my current computer (i7) benchmarks at about 3 ms using the default number of rounds.


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