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
--
security mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/security
