Anaconda 22.17+ enforces "good" passwords

[Chris Murphy]

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