How do I amend the PAM configuration to expire passwords to encrypt with new values? The Lynis security audit tool on my system has advised, “Check PAM configuration, add rounds if applicable and expire passwords to encrypt with new values.
I think we’re okay on this one. Here’s an explanation.
Linux passwords work by doing a one-way operation — usually, a cryptographic hash. This is similar to
$ echo -n foo|sha1sum
0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 -
… except sha1 is no longer considered a good choice for passwords. That hash is what’s stored. (Well, also with a “salt” so that all foo passwords aren’t identical. But, short explanation, it’s a hash of your password.) It’s theoretically impossible (or at least very hard) to go backwards from a hash to the source. Normally, it doesn’t even matter, because no one should even see the hash. Try cat /etc/shadow as a regular user — permission denied.
But, if they can grab it, they have unlimited time to try and break it. Usually, that’s done by running through a list of dictionary words. sudo cat /etc/shadow to see your password file as root. The format is separated by : characters; first the username, then the password (or !! for a locked account), followed by the date of the last password change (days since January 1, 1970, midnight UTC), followed by some stuff about password expiration policies. (More on which below.)
As computing power increases, the time to crack a password gets longer. So, one solution is to use slower hash functions. And one easy way to do that is to just do the hash a bunch of times — that’s the “rounds” it’s talking about. Basically, you hash the hash over and over. The result for the same input and number of rounds is stable. That makes it a tiny bit slower to check any one given password (like when you log in), but hopefully much slower to run millions of possibilities to try to crack a stolen hash.
Now, to Fedora Linux. We’ve used sha512crypt for so long that I don’t remember, and I think with 5000 rounds. That’s still considered “probably fine”, but with cloud-based attacks, it’s time to switch to something stronger. That’s what the tool is suggesting — but, honestly, it could be smarter here, because the algorithm chosen is defined in /etc/login.defs, and if the tool looked, it could see that for Fedora Linux 35, we now default to yescrypt. yescrypt is a modern algorithm designed for this purpose and much harder to break. It doesn’t have "rounds’, but does have a “cost factor”. I see that that’s set to the default of “5” in /etc/login.defs. If you want, you could increase that (up to “11”, the maximum value, heh) — but it’s probably not a big deal. (Other risks are much larger.)
If you look back to your /etc/shadow file (as root, of course — but very careful not to mess up the file because you won’t be able to log or possibly even boot if it’s corrupted). You should see that the password hash string starts with $y$. That signifies that it is using yescrypt. However, if if you upgraded from an older release, it might be $6$ — the prefix for sha512crypt. (See man 5 crypt for more possibilities!) So here’s where the advice on expiration comes in. If your password was hashed with the older algorithm, changing it (even to the same thing, sssh, don’t tell anyone) will instead give you one with the new algorithm. And if you have multiple users on the system, setting their passwords to expire will force them to make this change.
I don’t think expiring passwords is in general good advice. I mean, don’t use the same password everywhere, and change occasionally, but it’s usually better to have a strong password you remember for five years than a weak one you change every month. And I don’t think they’re suggesting otherwise, just using that as a tool to force updates.
But if you’ve got a $y$ password already (the case for all passwords created with Fedora Linux 35), there’s nothing to do here. And even if you started with an earlier release, if you’re the only user, just typing passwd to update once should take care of it.
Whew, that was longer than I meant. I am procrastinating from some other things I have to do. Hope it’s useful!
1 Like
Oh! And the actual answer to your question:
-
Change the password algorithm (but don’t, as it’s already the strongest available) or rounds / CPU cost by editing
/etc/login.defs -
And actually,
/etc/login.defsis where the configuration for password expiration is too.
So it’s kind of weird Lynis doesn’t just say that. 