> On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač <mitr@xxxxxxxxxx> 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 -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
