4.4.22 disables SHA256 for no reason

[msharov]

SHA-256 is still a strong hash, with no currently known attacks, yet you have now marked it as LEGACY and are forbidding its use. This is a mean thing to do. Please reinstate.

[solardiz]

Not "for no reason". Please see e334b06#r51670865 and #35.

However, forcing password changes might be unnecessarily harsh, and the upgrade from sha256crypt to sha512crypt might be too minor to force it like that.

[zackw]

Note that libcrypt does not set policy. We export one function, crypt_checksalt, that reports compiled-in information about hashes that are supported. Before 4.4.22, it only told callers whether any given hash had been enabled at compile time (CRYPT_SALT_OK) or disabled at compile time (CRYPT_SALT_INVALID). The change in 4.4.22 was to add a third possible return value, CRYPT_SALT_LEGACY, which is used for hashing methods that we don't think are strong enough for new hashes. In other words, passwd(1) should not use those methods. Existing hashes using those methods will still be accepted by our crypt and crypt_r* functions.

Based on the bug reports we've been getting since 4.4.22, it seems that there is some implementation of login(1), I don't know which one, that calls crypt_checksalt and refuses to authenticate a user whose hash is reported as LEGACY. I would consider this to be a bug in that implementation of login. The only thing I ever expected login to do with a LEGACY hash is re-hash the user's existing password with a non-LEGACY method upon successful login.

I'm honestly surprised to learn that software that calls crypt_checksalt even exists. It's a stub for a planned API allowing runtime configuration of which hashes are enabled, which I designed way back in 2018 (see #4 and #26) and then never got around to implementing. I figured I would reach out to the PAM people once a prototype existed.

Could you please provide more details about the system where a password hashed with sha256crypt is no longer accepted for authentication?

[msharov]

Those are not good reasons.

A single bit of difference in cracking strength is negligible for any practical purpose. Leaking password length is also irrelevant, because nobody uses passwords longer than 32 characters, and if they do, knowing whether a password is 32 chars or 33 gives no practical benefit to the attacker; neither is practical to crack.

The cost of moving to sha512, on the other hand, is the increase in the basic library capabilities required. sha256 is already used everywhere else for other purposes, so it makes sense to support sha256 hashed passwords, but there is no other use for sha512. Its greater collision resistance has no practical significance and the whopping 64 bytes of hash size is much to big a price for essentially no benefit.

And anyway, libxcrypt is only used for hashing system passwords, not for website password databases, so there is no reason to be concerned about cracking strength in the first place. If an attacker can read /etc/shadow, he already has root access, and is able to get your passwords in a multitude of ways much easier than brute force cracking. Your forced "improvements" do little more than annoy people with no practical benefit.

Of course, I seem to be wasting my time here. From reading your other comments I see that you have already decided to impose this new policy whether we like it or not. I have already downgraded to 4.4.20 and will just block any further upgrades from you. Feel free to close the bug and ignore me as I will ignore you.

[zackw]

@msharov I think we were both writing responses at the same time. Again, could you please provide more details about the system where a password hashed with sha256crypt is no longer accepted for authentication? I think this is actually a bug in your login and would like to discuss this with its maintainers.

[ldv-alt]

On Thu, Jun 10, 2021 at 06:43:28AM -0700, Zack Weinberg wrote: Note that libcrypt does not set policy. We export one function, `crypt_checksalt`, that reports compiled-in information about hashes that are supported. Before 4.4.22, it only told callers whether any given hash had been enabled at compile time (`CRYPT_SALT_OK`) or disabled at compile time (`CRYPT_SALT_INVALID`). The change in 4.4.22 was to add a third possible return value, `CRYPT_SALT_LEGACY`, which is used for hashing methods that we don't think are strong enough for __new__ hashes. In other words, `passwd(1)` should not use those methods. _Existing_ hashes using those methods will still be accepted by our `crypt` and `crypt_r*` functions. Based on the bug reports we've been getting since 4.4.22, it seems that there is some implementation of `login(1)`, I don't know which one, that calls `crypt_checksalt` and refuses to authenticate a user whose hash is reported as LEGACY. I would consider this to be a bug in that implementation of `login`. The only thing I ever expected `login` to do with a LEGACY hash is _update the stored hash to a non-LEGACY method_ upon successful login. I'm honestly surprised to learn that software that calls `crypt_checksalt` even _exists_. It's a stub for a planned API allowing _runtime_ configuration of which hashes are enabled, which I designed way back in 2018 (see #4 and #26) and then never got around to implementing. I figured I would reach out to the PAM people once a prototype existed.

It's pam_unix, the culprit is linux-pam/linux-pam@4da9feb This libxcrypt bug report is incorrect, I suggest closing it.

[msharov]

My Arch distribution upgraded to 4.4.22 recently and I have ran system updates yesterday. After rebooting, I was unable to login. Logging in as root forced me to change the password, after which the login failed. I had to boot from external media and try stuff cluelessly and fruitlessly for a few hours, which annoyed me to no end. Finally, I checked Arch website, where your hash deprecation was front page news. So then it became a bit more clear that my sha256 passwords were the problem, not some password expiration issue as PAM kept telling me. Root login was failing because my root partition is normally mounted read-only, and so can't change the password at login. Changing the password simply created another sha256 hash because I have that specified in PAM configuration. Anyway, downgrading libxcrypt to 4.4.20 solved the problem, and pacman can be told which packages should not be upgraded. So that's a that for now, I guess, until I get around to rewriting my login program without PAM.

[solardiz]

Not to defend the bad experience you got with Arch overall (it does sound like a distro bug to me, and perhaps some package will need to be fixed), but to address a specific misunderstanding:

Leaking password length is also irrelevant, because nobody uses passwords longer than 32 characters, and if they do, knowing whether a password is 32 chars or 33 gives no practical benefit to the attacker; neither is practical to crack.

Quoting from a comment I wrote in #35:

"in sha256crypt there are very noticeable (tens of percent) differences in running time for realistic and attack-relevant password length ranges - e.g., for 7 vs. 8 or 11 vs. 12 characters, with the exact thresholds varying by salt length. (For sha512crypt, similar slowdowns occur at much higher lengths - tens of characters - so not practically relevant as an infoleak.)"

[ldv-alt]

I suggest closing this libxcrypt bug and tracking the pam_unix bug in linux-pam/linux-pam#367 instead.

[solardiz]

From reading your other comments I see that you have already decided to impose this new policy whether we like it or not. I have already downgraded to 4.4.20 and will just block any further upgrades from you. Feel free to close the bug and ignore me as I will ignore you.

I don't know who you meant by "you" here, but FWIW my role in this is merely providing technical expertise. Personally, I never suggested forcing password changes. I understand you're annoyed by the bad experience you had, but I seriously doubt anyone intended a change to any of the packages discussed here to result in you wasting hours, and I sincerely hope a fix will be made - most likely to Linux-PAM as @ldv-alt and @zackw suggest. No one is ignoring you here.

[msharov]

My apologies. It appears that PAM is the one at fault here. I have been annoyed at them before :)

[zackw]

@solardiz I'm tempted to resolve the sha{256,512}crypt part of this argument by removing sha512crypt from the strong set, thus pleasing no one. ;-)