On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač
>> 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
>> 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.)