4.4.22 forces new password - looks out of root account

[andyrtr]

Updating from 4.4.20 to 4.4.22 forces the user to set up a new password. The same is forced for root login. But that fail and no root login is possible anymore. I had to chroot into the system to rollback the update to be able to login again.

andyrtr@workstation64:[/tmp/libxcrypt/trunk]$ LANG=C su Password: You are required to change your password immediately (administrator enforced). su: Authentication token manipulation error

Any idea how to debug this further?

[besser82]

Sorry, for replying a bit late.

What are the first five characters of the hashed passwords for the root user in /etc/shadow on your system? When did you change it the last time? There are some hash methods, that are considered too weak to be used for computing password hashes, which may be your problem.

The mechanism for identifying such hashes has been included in libxcrypt and Linux-PAM since some releases, but was not enforced until libxcrypt v4.4.21.

[andyrtr]

root:$1$mg...

It's not a complex pw and I usually don't change it (a privat home system, not critical).

[besser82]

Whoa, md5crypt is ancient… I can assume safely you didn't change it since 2007 or so?

The md5crypt method is really dangerously weak: https://www.cvedetails.com/cve/CVE-2012-3287/

I'd really recommend you to change the password, so it will get hashed with the (yet to be considered) strong sha512crypt method, and libxcrypt will be happy with it.

The change in v4.4.21 was really intended to make users aware of such old hashes, and as far as I can see, it works properly.

Besides this, I have no idea, why your system locks you out of the root account or doesn't allow to change your password immediately after logging into the root account. I'm using Fedora and have tested the migration there, and it even works for the root account, if PAM wants me to change my password, because of a weak hashing method used for it. Possibly you have any special security configuration somewhere in your system, preventing you to change the password during login.

BTW: I just found your mail in my spam folder. Aber natürlich spreche ich muttersprachlich deutsch. ;)

[andyrtr]

Confirmed. Changing my pw to a new one (and back) seems to fully solve this issue.

Well, this is an issue you can run into when your rolling release distro works so well that you never have to reinstall it again... Now we need to work out a safe way for users that may run into this issue the same way. Thanks for your help.

[besser82]

You're welcome! Let's try work out a way using email and native language.

[eworm-de]

To recap... The issue happens if you set the old password again? Please CC me in your mail conversation... (I am the downstream maintainer.)

[andyrtr]

With the old pw used again everything works well because the new sha512 is used.

The update path was broken for me. The user was forced to set a new pw but for any direct root login or "su" it immideatly failed as stated here at the beginning.

I guess this should be reproducible using "ENCRYPT_METHOD=md5 passwd".

[msharov]

Changing the password does not fix the problem if you have specific hash set in the pam configuration. Doing that was previously recommended for setting the hash and its parameters, such as:

password required       pam_unix.so try_first_pass sha256 shadow rounds=131072

With this configuration in place, changing the password does log you in, but the password remains stored as sha256 and you get prompted to change the password again on the next login.

Additionally, these forced password changes fail if the root partition is mounted read-only. I keep it that way at all times except when upgrading. Failing to change the password fails the login, rendering the system unbootable. Better hope you still have some removable media to boot from.

Perhaps you should seriously rethink your heavy handed policy of stuffing settings down our throats.