Bug 12762

Summary: shadow: Slow password generation since shadow-utils >= 4.9
Product: IPFire Reporter: Michael Tremer <michael.tremer>
Component: aclAssignee: Adolf Belka <adolf.belka>
Status: CLOSED FIXED QA Contact: Arne.F <arne.fitzenreiter>
Severity: - Unknown -    
Priority: - Unknown - CC: peter.mueller, peter.mueller
Version: 2   
Hardware: unspecified   
OS: Unspecified   

Description Michael Tremer 2022-01-16 12:44:45 UTC
shadow-utils has changed how they gather entropy and it looks like they have made some mistakes which make entropy generation rather slow (Arne's system took more than 10 minutes to generate a salt).

Since more modern alghorithms are available and libxcrypt is building great functions to easily use them in third-party software, we should look at migrating our salted passwords from SHA512 to yescrypt (https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Yescrypt-PW-Hashing).

Arne has reverted the latest release because of this problem: https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=14aa983025562b72ee62a1c7515b25c680658516
Comment 1 Adolf Belka 2022-01-17 22:08:45 UTC
So I have rebuilt shadow using 4.11.1 as there have been a couple of updates since I submitted the original 4.9 version. I added --with-yescrypt to ./configure and changed the hash type in logs.def to yescrypt.

I didn't add --without-sha512 in ./configure as I wasn't sure if shadow needed this to be able to read the hashes as well as create them.

Anyway I then installed the built iso onto a vm on my testbed and the root password was accepted with no problems and no slowness
.
After full installation I checked the /etc/shadow file and the password hash starts with $y for yescrypt instead of the existing $6 for sha512 so it is working okay.

I will submit the patch for it next.
Comment 2 Adolf Belka 2022-01-18 09:22:48 UTC
Patch submitted to dev mailing list and patchwork.

https://patchwork.ipfire.org/project/ipfire/patch/20220118091455.1453-1-adolf.belka@ipfire.org/
Comment 3 Michael Tremer 2022-01-18 09:26:24 UTC
(In reply to Adolf Belka from comment #1)
> So I have rebuilt shadow using 4.11.1 as there have been a couple of updates
> since I submitted the original 4.9 version. I added --with-yescrypt to
> ./configure and changed the hash type in logs.def to yescrypt.

Perfect.

> I didn't add --without-sha512 in ./configure as I wasn't sure if shadow
> needed this to be able to read the hashes as well as create them.

We will still need support for the old hash because existing systems have it stored in that format. And generally I do not think it is worth switching this off.

> Anyway I then installed the built iso onto a vm on my testbed and the root
> password was accepted with no problems and no slowness

Yay.

> After full installation I checked the /etc/shadow file and the password hash
> starts with $y for yescrypt instead of the existing $6 for sha512 so it is
> working okay.
> 
> I will submit the patch for it next.

Cool. I sent a question on the list because I didn't see your response on here. So please ignore that.
Comment 4 Adolf Belka 2022-01-18 12:13:51 UTC
I ran a further test with my vm testbed.

Password was changed to a different one to the one in a backup. The changed password is hashed with yescrypt and works.

Carried out backup and password was changed back to what was in the backup, with the old sha512 hash. Confirmed by checking in /etc/shadow . This password also worked.

Then running setup I set the password to the same as it was. Confirmed in /etc/shadow that the hash was now based on yescrypt. That password worked fine.

The backup has both the root user and another user with restricted rights. So I ended up with a shadow file with root with a yescrypt hashed password and the other user with an sha512 hashed password.
Both passwords work.

So have confirmed that any new password created is yescrypt hashed but any existing sha512 hashed password will still be usable.
Comment 5 Michael Tremer 2022-01-18 15:02:50 UTC
Perfect. Thank you for confirming. This is exactly what we need.
Comment 6 Peter Müller 2022-01-18 21:25:06 UTC
https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=5b28df47a5f94bf05cd19de1439e6cf78307b96f

Not setting to MODIFIED since this is only my temporary branch for C164.
Comment 7 Adolf Belka 2022-01-27 14:48:32 UTC
The patch has been merged into next for CU164

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5b28df47a5f94bf05cd19de1439e6cf78307b96f
Comment 8 Adolf Belka 2022-04-01 21:02:50 UTC
Core Update 164 has been released with this fix.

https://blog.ipfire.org/post/ipfire-2-27-core-update-164-released