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 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. I think such a policy needs to involve the security team, and possibly some work that there just isn't time for before Fedora 22 although I could be wrong about that part. Changing the number of rounds used to arrive at the password hash gives breathing room both security wise, and time wise for a better and stronger strategy. Among other burdens to overcome mentioned in that FESCo ticket, I think it's a significant practical problem to have a complex password policy without a guideline for the user by which they can create a minimally compliant password in a single attempt. Right now, it's a guessing game. Since we're very nearly at feature freeze, no guidelines draft exists, no translations done, I think it's difficult (for me at least) to imagine the current behavior being foisted on users. Shooting in the dark to achieve almost no meaningful change in security I think is what will actually make more users mad than any philosophical complaint. So since I expect this to be reverted, I think Fedora security minded folks and experts need to chime in with an alternative that can mitigate brute force attack concerns that doesn't require a password quality change. - A minor point, just a note. It looks like anaconda uses authconfig, not passwd, and the resulting /etc/shadow contains a 16 character salt. Meanwhile, passwd uses an 8 character salt. I'm not sure how significant this is, but I filed a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1195110 ---- http://www.tarsnap.com/scrypt/scrypt.pdf Table 1 (The paper includes caveats about the table on the previous page; actual costs today would be different, however relative costs are probably about the same). Noteworthy is the weakness of 40 character test passphrases (column 5) compared to 10 random characters, let alone 8 random characters. I really think the user passphrase cat is out of the bag, there's just no possible way to get that under control on the user side without *significantly* increasing the requirement well beyond what Anaconda proposes. And therefore all the more reason to look at other ways to mitigate the concerns. All the more reason to look at increasing the number of SHA512 rounds we're using today; and hopefully by Fedora 23 or Fedora 24, some kind of KDF can be decided upon to make such attacks even more expensive. Possibly a standardized one, which is supposedly due sometime in the 2nd quarter this year. https://password-hashing.net/timeline.html https://password-hashing.net/index.html ---- OK and a bit of hopefully skillful trolling. I found this for 32 month old OS X 10.8 (two major releases ago) https://hashcat.net/trac/ticket/75 The relevant parts: SALTED-SHA512-PBKDF2 Iteration count varies based on check done at hash generation time. OS X 10.10 has been out some months and hashcat doesn't have OS X 10.10 support yet, and they distinguish between each major OS X version 10.4 through 10.9. Clearly Apple changes there hashing method between each OS X release. Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
