> If the user has a super secure password shared with a different, compromised service, libcrack will not detect that.

There's a module[0] for that (TM).

> Expiry results in passwords like: (prefix)Dec2020, (prefix)5

libcrack can enforce similarity and rotation checks too [1].

> or cycling the last 2/3 entries.

There's also another module[2] just for that.

> Keys can be relatively easily revoked and are guaranteed not guessable.

You're right but, a good password policy and infrastructure is not a simple straw man which can be set alight with a simple match. PAM can be a bit hard to understand but, once understood, it's pretty easy to create complex rules and flows.

If you get your workstation compromised somehow, you can always lose your keys. Then you need another password on top of your key to keep it encrypted.

At the end of the day, a good security policy is required. Keys, passwords, fingerprints and other identifiers are just tools. If you can design your defenses and moats well, you can secure your system with any method you want.

[0]: https://github.com/skx/pam_pwnd

[1]: http://www.linux-pam.org/Linux-PAM-html/sag-pam_cracklib.htm...

[2]: https://linux.die.net/man/8/pam_pwhistory

> libcrack can enforce similarity and rotation checks too [1].

How can it do that without the server storing plain text passwords?

Unless you're root, you enter your current password first for verification already?

Ah, ok, that makes a lot more sense. I was worried that the password history was stored somewhere.

> Unless you're root

I'm not sure I get this part, why does being root change things?

Normally PAM doesn’t ask for your current password during password changes if you’re root.

Also, root can change any user’s password without entering the current one.