Remove password aging

[alejandro-colomar]

I intend to remove it in 4.21, and deprecate in 4.19.

Passwords should never expire. It has been proved to decrease password safety.

The following features and/or programs will be deprecated in 4.19:

• expiry(1) // To be removed in 4.20
• chage(1):
  • -I,--inactive (also the interactive version)
  • -m,--mindays (also the interactive version) // To be removed in 4.20
  • -M,--maxdays (also the interactive version)
  • -W,--warndays (also the interactive version)
• passwd(1):
  • -k,--keep-tokens
  • -n,--mindays // To be removed in 4.20
  • -x,--maxdays
  • -i,--inactive
  • -w,--warndays
• useradd(8):
  • -f,--inactive
• usermod(8):
  • -f,--inactive
• login.defs(5):
  • PASS_MIN_DAYS // To be removed in 4.20
  • PASS_MAX_DAYS // Remove it from the default file in 4.20
  • PASS_WARN_AGE // Remove it from the default file in 4.20
• /etc/default/useradd:
  • INACTIVE
• shadow(5):
  • sp_lstchg: Restrict to just the values 0 and empty.
  • sp_min // To be ignored in 4.20
  • sp_max
  • sp_warn
  • sp_inact

Distros should make sure to remove those 3 values from login.defs(5) ASAP. That will make sure that the transition from 4.20 to 4.21 will be smooth. These programs will fail if such a configuration is specified in 4.21.

Cc: @stoeckmann , @thesamesam , @floppym , @jubalh , @ikerexxe , @zeha , @hallyn

---

Here are some statistics of the PR:

$ COLUMNS=999 git diff --stat master..HEAD \
| grep '^ [^ ]' \
| tr / ' ' \
| awk '{print $1}' \
| sort \
| uniq \
| while read -r f; do
        echo $f;
        git diff --stat master..HEAD -- $f \
        | tail -n1;
done;
1533
configure.ac
 1 file changed, 3 deletions(-)
doc
 1 file changed, 3 insertions(+), 8 deletions(-)
etc
 1 file changed, 6 deletions(-)
lib
 10 files changed, 18 insertions(+), 220 deletions(-)
man
 35 files changed, 6 insertions(+), 1371 deletions(-)
po
 1 file changed, 2 deletions(-)
src
 12 files changed, 54 insertions(+), 1432 deletions(-)
tests
 1472 files changed, 18 insertions(+), 32517 deletions(-)

---

Here's what NIST and Microsoft say about this:

NIST
   NIST SP 800-63-3
       In 2017-06, NIST (National Institute of Standards and Technology)
       published NIST SP 800-63-3 <https://pages.nist.gov/800-63-3/> (Digital
       Identity Guidelines), which —among other documents— contained
       NIST SP 800-63B <https://pages.nist.gov/800-63-3/sp800-63b.html>
       (Authentication and Lifecycle Management).

       This 3rd revision of NIST SP 800-63 superseded NIST SP 800-63-2
       <https://csrc.nist.gov/pubs/sp/800/63/2/final> (Electronic
       Authentication Guideline), from 2013-08, which was withdrawn in
       2017-06-22.

       NIST SP 800-63B recommended in §5.1.1.2
       <https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver>
       (Memorized Secret Verifiers), paragraph 9, that passwords should not
       expire periodically.

              Verifiers SHOULD NOT require memorized secrets to be changed
              arbitrarily (e.g., periodically).  However, verifiers SHALL
              force a change if there is evidence of compromise of the
              authenticator.

       NIST SP 800-63-3 was amended in 2020-03-02, but didn't change this
       recommendation.

   FAQ
       In 2017-07, NIST published a FAQ page
       <https://pages.nist.gov/800-63-FAQ/> clarifying doubts about
       NIST SP 800-63.

       In 2018-04-30, an entry clarifying §5.1.1.2 was added
       <https://github.com/usnistgov/800-63-FAQ/commit/9a87d495088d>.

       That entry is currently numbered as B05
       <https://pages.nist.gov/800-63-FAQ/#q-b05> and contains the following
       text.

              Q-B05: Is password expiration no longer recommended?

              A-B05: SP 800-63B Section 5.1.1.2 paragraph 9 states:

                            “Verifiers SHOULD NOT require memorized secrets to
                            be changed arbitrarily (e.g., periodically).
                            However, verifiers SHALL force a change if there
                            is evidence of compromise of the authenticator.”

                     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.

   NIST SP 800-63-4
       In 2025-07, NIST published a new revision of the Digital Identity
       Guidelines: NIST SP 800-63-4 <https://pages.nist.gov/800-63-4/>, which
       —among other documents— contains NIST SP 800-63B-4
       <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf>
       (Authentication and Authenticator Management).

       This 4th revision of NIST SP 800-63 superseded NIST SP 800-63-3
       <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf>,
       which was withdrawn in 2025-08-01.

       NIST SP 800-63B-4 is more strict than NIST SP 800-63B-3 regarding
       password expiration, and in §3.1.1.2
       <https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver>, prohibits
       periodic password expiration.

              6.  Verifiers and CSPs SHALL NOT require subscribers to change
                  passwords periodically.  However, verifiers SHALL force a
                  change if there is evidence that the authenticator has been
                  compromised.

Microsoft
       Some corporations have changed their security policies similarly.

       In 2019, Microsoft released version v1903 of Windows 10.  With it, it
       also published the Security baseline (FINAL) for Windows 10 v1903 and
       Windows Server v1903
       <https://learn.microsoft.com/en-us/archive/blogs/secguide/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903>.

       That publication drops periodic password expiration from their policy.

              •  Dropping the password-expiration policies that require
                 periodic password changes.  This change is discussed in
                 further detail below.

---

See also:

• https://pages.nist.gov/800-63-FAQ/#q-b05
• https://learn.microsoft.com/en-us/archive/blogs/secguide/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903

---

Revisions:

v2

• Only remove some features of chage(1), but not the entire program.
• Keep support for sp_lstchg == 0.
• Keep passwd(1) -e.

[patrakov]

PCI DSS 4.0.1:

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
Passwords/passphrases are changed at least once every 90 days, OR
The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

The second alternative is so vague that there is no way to implement it except for buying a black box that claims to do it.

But in any case, PCI-DSS-compliant organizations cannot rely on shadow passwords, as shadow-utils do not maintain a history of 4 old passwords (to prohibit their reuse) required by 8.3.7.

[alejandro-colomar]

@patrakov

PCI DSS 4.0.1:

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
Passwords/passphrases are changed at least once every 90 days, OR
The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Thanks!

The second alternative is so vague that there is no way to implement it except for buying a black box that claims to do it.

Agree. :D

But in any case, PCI-DSS-compliant organizations cannot rely on shadow passwords, as shadow-utils do not maintain a history of 4 old passwords (to prohibit their reuse) required by 8.3.7.

Sounds right. Regardless, it would be good to contact them and let them know about NIST prohibiting periodic password rotation; I'll do that if nobody does it first.

For those needing to work on a PCI-DSS-compliant environment, here's a useful tip (not from me):
https://lwn.net/Articles/1052638/

Change your password quickly 4 times, and then change it a 5th time to the good one you remember. ;)

[stoeckmann]

But in any case, PCI-DSS-compliant organizations cannot rely on shadow passwords, as shadow-utils do not maintain a history of 4 old passwords (to prohibit their reuse) required by 8.3.7.

That's not entirely true. Since shadow supports PAM, a module can be used there to enforce the policy. See https://github.com/linux-pam/linux-pam/blob/master/modules/pam_pwhistory/pam_pwhistory.8.xml

[alejandro-colomar]

Okay, I'm drafting a plan.

I think expiry(1) can go away already; its functionality is superfluous, and I don't think it would be required by the regulations we've seen. I'll open a PR for this.

Another thing I think can go away is the minimum password age (shadow(5)'s 4th field). Having a minimum password age is something I haven't seen in any regulations either, and can actually be dangerous if a password has been leaked before the minimum age (so that the attacker would be allowed to connect, because the password can't be changed). I'll open a PR for this.

[stoeckmann]

I would also like to see if PASS_MAX_DAYS and PASS_WARN_AGE are commented out. Just like is done with some other login.defs variables. This would finally lead to distributions which use default settings to have no more 99999 max days in their shadow files. With 4.19, they might eventually notice with chage -l that their accounts actually have a limit, although a huge one.