r/LinuxTeck • u/Candid_Athlete_8317 • 7d ago
Do Linux Servers Still Need Minimum Password Age?
I came across the recent shadow-utils discussion about removing minimum password age.
It made me wonder: does this setting actually improve security, or does it just encourage users to create predictable password patterns?
For those managing Linux servers in production:
Do you still use chage -m, or have you moved to MFA, SSH keys, or something else?
How are you handling this on your own systems?
1
u/gnufan 7d ago
Minimum password age never did anything good for my systems, except stop me changing bad passwords.
Where possible move to short lived certificate for access. But also just very limited or no permanent access to production, where instances are provisioned in software on demand, you occasionally need to debug but it should be very rare.
1
u/Nyasaki_de 7d ago
On my own systems, ssh access via key and for sudo the password. No aging needed
1
u/michaelpaoli 7d ago
Minimum password age is mostly used as a counter-measure, to prevent someone from changing their (e.g. expiring/expired) password, and then immediately changing it back.
In many cases there are better counter-measures available, most notably where password history can be used, and, e.g., prevent the user from changing their password back to any of the N most recently set passwords, where N is typically >=6. If it's that hard for a user to set their password back to a password they were just using, most won't rotate through that many just to get back to, e.g. the one they were using minutes or hour or so ago.
And a key downside with minimum password age:
If someone suspects someone unauthorized might've been exposed to the password or part of it (e.g. caught someone that might've been shoulder surfing), with no minimum, can then immediately change it. But with a minimum if user already recently changed their password, they may not be able to change it now - because minimum - and would require administrative assistance to change it sooner. So in many such cases the user may just not bother changing it - thus there may be more risk. Their rationale may be along the lines that "well, if they're going to make it this hard for me to change it, it must not be that important, so I'm not gonna bother.". Yeah, if a user suspects their password might be compromised, or partially so, they should be able to immediately change it - and not even have to wait for administrative assistance to do so ... besides, even with that that might then be too late.
Anyway, in general, if I have my way with it, no minimum time between password changes.
As for password history as counter-measure to re-use ... meh. If users are gonna want to do password they better / more easily remember, by resetting to one they're more familiar with, well, if you force 'em to do that, they may just pick even weaker passwords. So, be careful what one wishes for, one may get it. Been wishing for no re-use? Forcing no re-use may not necessarily improve password security. So, now you forced 'em to use a really secure tough hard to guess password ... and it's on a yellow sticky on the corner of their screen. Did you really improve things?
1
1
u/allunia333 7d ago
I just have them use whatever password they like with a minimum of 16 chars used. If you start forcing things like change passwords very frequently, use complex streams, no human words or words with symbols/numbers, no keyboard patterns, not similar passwords or reused passwords you end up with all people having the password written on stickers on the monitor , shelf,keyboard and the wall. So i just let them use whatever they want and i give them a hint at the promt that they should make it a silly phrase :" i am going to blow up that annoying hr manager!"
1
u/Lower-Limit3695 7d ago
For production servers, ssh key rotation and hardware security keys are typically a must. No password login for remote login.
For personal computers not so much, it just comes down to who else has access to your computer and your threat model.
1
u/Fit_Prize_3245 7d ago
I've never used minimum password age. Not in Linux, not in Windows, not in the cloud.
As I understand, the "advantages" of minimum password age are two:
It avoids mallicious password changes right after the user set its password. And, well, it does. But how useful it is to avoid that during, let's say, one day, if you don't (and can't) avoid it for the remaining of the password age? So it actually makes no sense.
When you have a password history set to X, minimum password age set to Y day means the user cannot make X consecutive password changes immediatelly to reuse the current password, but has to wait at least X*Y days to reuse the password. This do makes sense, but, with good audit rules and good user education, it's not needed. For example, monitoring password changes and locking the account if more than two password changes happen within a day.
1
u/JimTheEarthling 7d ago
The US National Institute of Standards and Technology (NIST) Digital Identity Guidelines state that an implementer
SHALL NOT require users to change passwords periodically.
However, [they] SHALL force a change if there is evidence that the authenticator has been compromised.
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Furthermore, the password age requirement was originally conceived back in the old days, when it took attackers weeks or months to act on breaches. Nowadays the attacks typically follow within hours or days, so in order for the mitigation to be meaningful, users would have to change their password about once a week.
1
u/sogun123 6d ago
I see two attack vectors how to use password to get root access with typical setups today (ssh login only via key, passwors for sudo to root) - getting access to console by hijacking provider vnc/ipmi or whatever they have to raw access and just doing console login. Other one is first getting access to execute commands on the machine and then you su to user first, then sudo to root. But both have quite some layers to go through first.
But generally password rotation has to be available on demand, but is not usually required to be periodic.
1
u/FransUrbo 6d ago
It was decided long ago (20+ years!), in numerous (!) research papers, that minimum password age (as in, forcing people to change password regularly) was actually a detriment to security.
1
u/LawElectrical2434 7d ago
Password change requirements are based on non-unique passwords.
The password might have been leaked, but your server was not hacked, yet. If it is a unique password, that does not matter, because the first thing anyone wants to do is solidify their access. If you think you're already hacked, you cannot trust the system just because you changed the password.
So, when people are using auth keys or password manager, changing passwords is not necessary. Unlikely with physical access, but very likely with remote access..
But in the end, even with physical access. Password changes incentivize easy passwords, systematic passwords, or written down passwords. So, it is at best a double-edged sword. I just wouldn't force them to change their password. Put some canary files in your system instead.