Anaconda 22.17+ enforces "good" passwords

[Miloslav Trmač]

> 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?

I don’t know that the algorithm makes a difference here; any hash checking slowdown we would be reasonably willing to endure for protection against dictionary attacks will not be nearly as effective as reasonable rate limiting.


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

AFAICT a good rate limiting / denyhosts-like blacklist would make the higher password quality requirement mostly unnecessary.  With rate limiting, strong password quality (beyond the “not obviously stupid” level of password quality) only matters against off-line attacks.  (The off-line attacks scenario includes encryption passwords, without well-deployed TPM use at least, so it is still a problem that needs solving, OTOH.)
     Mirek