On Mon, Feb 23, 2015 at 4:22 PM, Miloslav Trmač <mitr@xxxxxxxxxx> wrote: >> 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. OK, good. > 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. This comment I think is in scope for the FESCo ticket. It'd also be useful exactly how to obtain the "not obviously stupid" check. Is this some blacklist made of the top 100,000 most common passwords used in 2014 hacks? While I'm tickled at the idea of user interfaces literally saying "obviously stupid passwords will be rejected" just for the amusement factor, it's unlikely to happen that way. Plus, it's vague. So somehow this needs to be articulated to the user and this isn't straightforward and thus represents more work to be done. OS X at least does allow obviously stupid passwords. I don't even get a pw quality indication by default. I can use "moon" for example, which ends up not just being a login password but also unlocks the encrypted volume (root + home). I don't present this as model to emulate. It's presented as, two giant companies who have the resources and clout to enforce something different, and have a sane UI to go with it, yet still haven't done anything. So it's presented from the point of, I'm skeptical that this is a good area to expend resources while also troubling users who have already ignored password quality check advise (in Anaconda). -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
