The password expiry feature has expired! [LWN.net]

The password expiry feature has expired!

Posted Aug 7, 2026 23:37 UTC (Fri) by alx.manpages (subscriber, #145117)
In reply to: The password expiry feature has expired! by hailfinger
Parent article: Changes in shadow-utils password-expiration features

I can't believe nobody has tried that pun yet.

The shadow-utils change started with a PR of mine titled "Expire expiry(1)". :D https://github.com/shadow-maint/shadow/pull/1432 (It was later renamed to "Remove password aging", because it grew to do more than just removing expiry(1).)

Glad to see shadow-utils enforcing usable security from the tooling side.

Thanks! :-)

(If you'd like a voice from Europe, the German BSI has issued similar advice.)

It would be good to have links to those, so that any reader can find and use them.

I also found that the UK has something similar:

https://www.ncsc.gov.uk/collection/passwords/updating-your-approach

which says (among other things):

Don't enforce regular password expiry

    Regular password changing harms rather than improves security.
    [...]

to post comments

The password expiry feature has expired!

Posted Aug 8, 2026 0:46 UTC (Sat) by hailfinger (subscriber, #76962) [Link] (1 responses)

Link to the BSI Germany Baseline Protection (Grundschutz) mentioning password expiry and handling in the Grundschutz Compendium (2023 edition) section ORP.4.A23:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grund...

Quoting the relevant part of the document:
> ORP.4.A23 Regelung für passwortverarbeitende Anwendungen und IT-Systeme (B) [IT-Betrieb]
> IT-Systeme oder Anwendungen SOLLTEN NUR mit einem validen Grund zum Wechsel des Passworts auffordern. Reine zeitgesteuerte Wechsel SOLLTEN vermieden werden. Es MÜSSEN Maßnahmen ergriffen werden, um die Kompromittierung von Passwörtern zu erkennen. Ist dies nicht möglich, so SOLLTE geprüft werden, ob die Nachteile eines zeitgesteuerten Passwortwechsels in Kauf genommen werden können und Passwörter in gewissen Abständen gewechselt werden.
Sadly, the phrasing in the 2023 edition for "do not perform time-based password expiry" is using a "SHOULD", not a "SHALL".

Fortunately, there is a newer version destined to be used for the next Grundschutz++ edition (link to JSON in OSCAL format):
https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/...
Quoting from the relevant part of the document:
> 5. Anlassbezogene Passwortwechsel
> Diese Regelung legt fest, dass Passwörter nicht in festen Zeitabständen gewechselt werden. Ein Passwortwechsel wird ausschließlich anlassbezogen durchgeführt, insbesondere bei Verdacht auf Kompromittierung, nach festgestellter Weitergabe an unbefugte Dritte, bei einschlägigen Treffern in Leak-Datenbanken, nach Phishing-Vorfällen oder bei technischen Indikatoren für einen möglichen Missbrauch des Zugangs.
This newer version is clearly stating that only event-based password expiry is allowed. No exceptions.

BSI also has a press release covering this topic: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitt...

The password expiry feature has expired!

Posted Aug 8, 2026 13:15 UTC (Sat) by iabervon (subscriber, #722) [Link]

In general, changing a SHALL to a SHALL NOT directly is impractical. People will continue following the last version of the guidance that they've been audited to comply with until they can be audited to comply with a later version, and they can't comply with the later version if it's impossible to follow both at the same time, so you need to provide a migration path. (It doesn't apply to this case, but, in general, there may also be new requirements in the SHOULD NOT guidance that provide a replacement mechanism addressing the goals that the SHALL were for, where doing neither would be worse than continuing to follow the SHALL, and you want to say that people only stay in compliance if they implement the replacement first and get audited.)

The password expiry feature has expired!

Posted Aug 8, 2026 18:36 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link]

There's a good summary of the history of password expiry in the late lamented Ross Anderson's Security Engineering (third edition - available online) from the bottom of page 99 here: https://www.cl.cam.ac.uk/archive/rja14/Papers/SEv3-ch03.pdf

In it he says:

> The first systematic study by Yinqian Zhang, Fabian Monrose and Mike Reiter of the password transformation techniques users invented showed that in a system with forced expiration, over 40% of passwords could be guessed from previous ones, that forced change didn’t do much to help people who chose weak passwords, and that the effort of regular password choice may also have diminished password quality [2073]

That's their 2010 paper at the ACM Computer and Communications Security conference "The security of modern password expiration: an algorithmic framework and empirical analysis" - online here: https://dl.acm.org/doi/epdf/10.1145/1866307.1866328