Comment by SAI_Peregrinus

Fascinating. In other words:

In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).

I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.

There are also systems that keep a history of old passwords just to prevent you from reusing one.

The obvious solution is to have a Monday password, a Tuesday password, etc.

No, you can do it safely. The idea is to have the password renewal process also ask for the previous password.

This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.

To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.

Not if the check is done client-side, so the plain password never leaves you local domain. Of course the check being done client-side means that it isn't difficult to skip if you are inclined to make a smidgin of effort.

PCI requires multi-factor auth these days, so you’ll likely find now the ssh password will be your password plus a OTP at the end.

This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.

But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.

So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.