Changes in shadow-utils password-expiration features

pykello1 pts0 comments

Changes in shadow-utils password-expiration features [LWN.net]

LWN<br>.net<br>News from the source

Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments

LWN FAQ<br>Write for us

Edition Return to the Front page

User:<br>Password: |

Log in /<br>Subscribe /<br>Register

Changes in shadow-utils password-expiration features

We're bad at marketing

We can admit it, marketing is not our strong suit. Our strength is<br>writing the kind of articles that developers, administrators, and<br>free-software supporters depend on to know what is going on in the<br>Linux world. Please subscribe today to help us keep doing that, and so<br>we don’t have to get good at marketing.

August 7, 2026

This article was contributed by Alejandro Colomar

The shadow-utils<br>project provides the tools that handle /etc/shadow,<br>/etc/passwd, and other related databases; in<br>general, it manages users and groups on many Linux systems. While most<br>software releases are notable for what is added, the recent shadow-utils 4.20.0<br>release is most noteworthy for what has been removed. Specifically,<br>several utilities and functionality related to periodic password<br>expiry, which were deprecated in the December 2025 4.19.0<br>release, have been removed as planned. It is still possible to manage<br>some aspects of password aging with shadow-utils, but organizations<br>that depend on such features should start planning for their complete<br>removal within a few years.

Some history

The shadow-utils project has its roots in the original Shadow<br>Suite, written for SunOS in the 1980s, where /etc/shadow<br>seems to have been invented. Password expiration wasn't supported as<br>the old /etc/passwd<br>database doesn't hold this information.

It's unclear when password-expiration features were added to the suite, but<br>they are present in the first version committed to CVS in 1996. It seems likely<br>they were added in the first version of the suite. Back then—and until<br>very recently—it was common practice to periodically force password changes,<br>as it was believed that it would decrease the risk of unauthorized access.

However, that belief no longer seems warranted. A paper<br>published in 2015, "Quantifying<br>the security advantage of password expiration policies" found that<br>the benefit of password expiry is "relatively minor at best, and<br>questionable in light of overall costs".

In 2017, the US National Institute of Standards and Technology (NIST) published<br>an updated version (800-63B revision 3) of<br>its digital identity guidelines. Whether someone at NIST had read the paper is<br>unknown, but this revision recommended<br>against periodic password expiration. NIST published a FAQ in 2018 that explained<br>why it no longer recommended password expiration. If users know they will have<br>to change their passwords frequently, it said, "they often select a secret<br>that is similar to their old memorized secret by applying a set of common<br>transformations such as increasing a number in the password". Thus, rotation<br>provided a false sense of security since attackers could likely predict how a<br>user might change their password.

In 2025, NIST published revision 4 of the publication, and strengthened<br>the wording about periodic password expiration. This time, instead<br>of recommending against password expiration, the policy prohibits<br>it. Users are allowed to rotate passwords periodically, but the<br>verifying software is not allowed to require this. The wording also<br>changed from referring generically to arbitrary changes to<br>specifically mentioning periodic changes.

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

The changes in shadow-utils 4.20.0 move the project closer to today's<br>best practices for password management by disabling some features that<br>force password changes. The expiry<br>command, which checks and enforces password-expiration policy, has been<br>removed. This is a first step in shadow-utils deprecating and removing<br>password-expiration features, and expiry was redundant with<br>other programs as well. For<br>example, it is possible to use getent<br>to retrieve information about a user's password-expiration settings. A password<br>can be expired immediately using passwd -e,<br>which will force the user to reset the password on the next login.

The fourth field of /etc/shadow, which specifies the minimum number<br>of days until a user can change a password, is now ignored and removed if<br>present. There is no longer a minimum password age; it was a security<br>vulnerability in some cases, and also part of deprecating and removing<br>password-expiration features. It is a security vulnerability because it may have<br>prevented users from changing their password immediately, which may be necessary<br>if a user's password is compromised in some fashion.

Other changes

The groupmems<br>command, which allowed users to administer the members of their own group, has<br>been removed. Its functionality...

password expiration shadow changes utils features

Related Articles