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

August 7, 2026

This article was contributed by Alejandro Colomar

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

Some history

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

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

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

In 2017, the US National Institute of Standards and Technology (NIST) published an updated version (800-63B revision 3) of its digital identity guidelines. Whether someone at NIST had read the paper is unknown, but this revision recommended against periodic password expiration. NIST published a FAQ in 2018 that explained why it no longer recommended password expiration. If users know they will have to change their passwords frequently, it said, "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". Thus, rotation provided a false sense of security since attackers could likely predict how a user might change their password.

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

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.

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

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

Other changes

The groupmems command, which allowed users to administer the members of their own group, has been removed. Its functionality overlapped with the more powerful usermod command for root; since groupmems was not being installed as setuid root by distributions, it was useless for non-root users.

Support for the Data Encryption Standard (DES) and MD5 password-hashing algorithms has been removed, as they are insecure compared to more modern hashing algorithms. The default is now SHA512 if ENCRYPT_METHOD is not defined in the login.defs configuration file. However, other programs and libraries (such as libpam) also read this configuration file, and may still default to unsafe algorithms such as DES, so users should continue defining this variable explicitly, at least for some years.

The logoutd utility has been dropped. It was used to enforce login time and port restrictions as specified in the /etc/porttime configuration file. If that filename does not ring a bell, it is likely because it has not been used in some time; it is not mentioned in the Filesystem Hierarchy Standard's description of /etc, and none of the major Linux distributions package the logoutd utility these days—so it made sense to remove it from shadow-utils.

Outdated policies and workarounds

Some outdated policies still require password expiration. These policies, which are even required by some countries, are unfortunate. Some users we've spoken to are required by contract to expire their passwords, and shadow-utils must support them (or we'd force them to fork the programs, or worse).

While researching whether shadow-utils could remove password expiration, the maintainers found that Spain's National Intelligence Centre (CNI) has a policy requiring expiration, and it provides scripts using chage—among other programs—that set up systems to comply with its policies. These scripts are public, and are meant to be used by companies that must follow its policies. The maintainers of shadow-utils tried to contact CNI, but have not received an answer.

Several features related to password aging still remain in shadow-utils, but are deprecated and will be removed at a later date. For example, chage is still included, but several of its options for setting minimum password age have been removed and others are deprecated. The passwd, useradd, and usermod options related to aging of passwords are also deprecated.

Some fields of /etc/shadow cannot be removed yet, as explained above, as they are required by some policies and countries. However, they are deprecated, and will be removed eventually. This includes the third (date of last password change), fifth (maximum password age), sixth (password warning period), and seventh (password inactivity period) fields of /etc/shadow, and also the command options that handle these fields.

Users will not be able to enforce a minimum password age in shadow-utils 4.20.0 anymore, and there's no workaround for that. It is expected that the deprecated features will be supported for at least a few years, but organizations that have policies requiring unnecessary periodic password changes should plan to phase them out. It is our hope that removing these features will encourage better password policies and improve security.

[ Alejandro is one of the maintainers of the shadow-utils project. ]

Index entries for this article
GuestArticles	Colomar, Alejandro

to post comments

Expiry - and back to old

Posted Aug 7, 2026 17:30 UTC (Fri) by MortenSickel (subscriber, #3238) [Link] (10 responses)

We had a system at $PREVIOUSJOB with password expiry. You were not allowed to reuse the three last passwords, but as there was no minimum password age, after a while everybody knew you could change password three times with throwaway passwords and get back to your old trusty $PASSWORD...

(The system also demanded that the password was 8 charaters, no more, no less and it also just told you when you were to log in that 'Now you have to change yojr password before you can do whatever you had planned to do'...)

Expiry - and back to old

Posted Aug 7, 2026 18:52 UTC (Fri) by marekm (subscriber, #174682) [Link] (3 responses)

Hello, former maintainer here from long long ago (1995-2000).
Oldest version of which I still have a copy is shadow-3.3.1 from around August 1993. Back then I first had access to something new called the Internet (as a student of Wrocław University of Technology) and started using Linux (first Slackware installed from floppies, later Debian from release 0.93r6 until today).
Back then the shadow suite was under an old non-commercial license, there was some controversy about this, later the original author (J.F.Haugh) and other contributors agreed to change to the BSD license (first with the infamous advertising clause, later removed), and I offered to take over maintaining it.
Password expiration features were already implemented and haven't changed much since then. SunOS 4.x didn't have them with only the old /etc/passwd (the shadow suite replaced a few system utilities to add shadow support), proper /etc/shadow support was only added in the new SunOS 5.x aka Solaris 2.x. It also existed in SCO UNIX for backwards compatibility, in addition to a much more complex password database.
Some people were unhappy that existing software had to be modified to support shadow passwords (and some had to be made setuid root to read the password hashes from /etc/shadow), and later the PAM (Pluggable Authentication Modules) project has been created. (I'm not sure in hindsight if all the added complexity of PAM was really worth it - the setuid issue was mostly with X11 screen lock programs, which could simply have read the password hash of the invoking user right at startup and then drop privileges early, and do any possibly insecure graphical stuff only as the ordinary user.)

Expiry - and back to old

Posted Aug 7, 2026 19:55 UTC (Fri) by pwfxq (subscriber, #84695) [Link] (2 responses)

In my early days as a sysadmin, I remember logging a support call with Sun as the password ageing wasn't working in Solaris. I was told that it was broken in early versions of Solaris and I should upgrade to get a fix. IIRC, they claimed it was fixed around Solaris 2.4/2.5

(TBH, much was broken in early versions of Solaris. I believe the unofficial line was that Solaris 2.5 was the first working version)

Expiry - and back to old

Posted Aug 8, 2026 16:59 UTC (Sat) by ejr (subscriber, #51652) [Link] (1 responses)

Solaris 2.x / SunOS 5.x with x < 5 all has bad issues, iirc. Definitely caused some chaos above the BSD->SVR4 roll-out. Vague recollections that 2.4 could be made to work.

Expiry - and back to old

Posted Aug 17, 2026 19:06 UTC (Mon) by Yenya (subscriber, #52846) [Link]

Yes. 2.4 more-or-less worked, even on X/openlook workstations, and we got 2+ years uptimes with 2.5 on our main file/shell/mail/nfs/whatever-server.

Expiry - and back to old

Posted Aug 8, 2026 14:05 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (5 responses)

In a previous long mission at a customer's, we were forced to change passwords every 90 days. Needless to say that after a year you stop being creative. One day a guy in the next office was logging in an pronouncing his password while typing it, such as "May2010". I laughed and asked "ah, you're using May2010 as well?", and he replied "obviously, everyone is using the same trick as there's no way to remember so many different passwords; there are variations, most use the date of latest change, others use the date of next replacement". I was already convinced that password expiry prevented one from building up and remembering strong passwords, now I had a solid proof of it if a whole company uses only a few bits of entropy between all passwords... The easiest way to log into a system without being authorized was to first choose as a password the month+year then randomly try many different logins until one validates. It's great that this bad practice is finally disappearing, after having been forced onto everyone as something absolutely and evidently critical to the global security...

One thing though, companies (and sites) who dropped that bad practice should have clearly told their users and forced them to change the password for a robust, definitive one, because I'm pretty sure that many people having experienced this bad practice are now keeping their last weak password.

Expiry - and back to old

Posted Aug 8, 2026 17:01 UTC (Sat) by ejr (subscriber, #51652) [Link] (4 responses)

And if they'd allow spaces, general punctuation. and long lengths, pretty much all problems would have been solved. I wonder if there are LLM password guessers yet. Feed in a target's online presence, narrow the possible passwords?

Expiry - and back to old

Posted Aug 10, 2026 13:13 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (3 responses)

> And if they'd allow spaces, general punctuation. and long lengths, pretty much all problems would have been solved.

So true! I've been in a place where admins had a 3-char password containing a space. No password cracker by then managed to find it just because it wasn't possible to add a space to their alphabet in their config file! (this was in the 90s).

Expiry - and back to old

Posted Aug 10, 2026 17:06 UTC (Mon) by iabervon (subscriber, #722) [Link] (1 responses)

I wonder if any current crackers check whether your password is actually ●●●●●●●●. It should probably be prohibited under a rule that a password has to have at least a few different characters, but then it's also something that humans would tend not to think is actually your password, even if you accidentally told them it was.

Expiry - and back to old

Posted Aug 10, 2026 17:22 UTC (Mon) by ejr (subscriber, #51652) [Link]

They will once that comment is scraped and ingested. I doubt if folks still use purely dictionary-based crackers much, although I don't log the failed ssh attempt details before crowdsec blocks them.

Expiry - and back to old

Posted Aug 19, 2026 17:31 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

i added ctrl+enter escape in my password, but then no GUI supports entering that one.

Authorities have responsibilities too

Posted Aug 7, 2026 20:29 UTC (Fri) by jepsis (subscriber, #130218) [Link] (7 responses)

"The maintainers of shadow-utils tried to contact CNI, but have not received an answer."

In my view, CNI should be given a clear six-month period to respond, following reasonable and documented efforts to engage. If no response is received within that period, the project should be entitled to proceed on the basis that no objection has been communicated.

References: Ley 39/2015, Article 21; Organic Law 4/2001, Article 11.

Authorities have responsibilities too

Posted Aug 7, 2026 20:53 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (6 responses)

The shadow-utils project is not bound by Spanish law (or at least by this particular law), to my understanding. It's not as if CNI or the Spanish government contracted with shadow-utils to provide these features, or at least the article does not indicate such an arrangement.

It would probably be more convenient for CNI and others if they voluntarily complied, but that has to be weighed against the needs of the shadow-utils project. It seems that shadow-utils would like to avoid the outcome where CNI or someone else has to fork the software, so I imagine that there will be ongoing attempts to start a dialog. But six months, just to get an initial reply, seems a bit unreasonable to me.

Authorities have responsibilities too

Posted Aug 7, 2026 22:08 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (5 responses)

> The shadow-utils project is not bound by Spanish law (or at least by this particular law), to my understanding. It's not as if CNI or the Spanish government contracted with shadow-utils to provide these features, or at least the article does not indicate such an arrangement.

To clarify, no such arrangement exists. The only reason I tried to contact CNI is because I'd like to help end these bad security policies in my country. Seeing that they ignored me, I feel I've done my part, and it's now their problem (and also of anyone who has to comply; luckily, I don't). Whoever is affected/more interested will have to deal with them.

> It would probably be more convenient for CNI and others if they voluntarily complied, but that has to be weighed against the needs of the shadow-utils project. It seems that shadow-utils would like to avoid the outcome where CNI or someone else has to fork the software, so I imagine that there will be ongoing attempts to start a dialog. But six months, just to get an initial reply, seems a bit unreasonable to me.

Yup, I was hoping for a voluntary cooperation.

The way we've done it is interesting:

They don't need to fork (at least, not immediately), because the expiration functionality that they require is still there. However, they certainly must react immediately, as we've broken some scripts provided by them to the users of their policies.

I expect several possibilities in the short term:

They may not notice for some time. This depends on how much time one of their users takes until they run the lastest version and use the scripts to set up password expiration policies.

Once they notice:

A). They review the policy, and drop password expiration entirely (hopefully);

or B). They remove the commands that now fail, since they're not strictly required by the policy, and otherwise keep the policy.

Authorities have responsibilities too

Posted Aug 7, 2026 22:50 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (4 responses)

Funny thing:

I've followed the link we followed last time when we found the scripts that we broke. The link is now behind a login wall, so the scripts can't be read anymore.

This was the link: <https://www.ccn-cert.cni.es/es/guias-de-acceso-publico-cc...>

And here's the shadow-utils discussion where that link was mentioned: <https://github.com/shadow-maint/shadow/pull/1432#issuecom...>

I hope that at least, since they've most likely read my email and spent some time closing the scripts, that they'll also spend some effort in changing their policies.

Authorities have responsibilities too

Posted Aug 7, 2026 22:55 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

Even more funny: their policies are still public, but the scripts are closed ('Redes clasificadas'). The page says last change is from August 2026. It would be interesting if they closed it exactly today. :D

<https://www.ccn-cert.cni.es/es/guias.html>

Authorities have responsibilities too

Posted Aug 7, 2026 22:58 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (2 responses)

Oh no, they claim it's public, but when you try to read them, the policies are also closed behind a login wall. :(

Authorities have responsibilities too

Posted Aug 9, 2026 6:56 UTC (Sun) by bmork (subscriber, #88411) [Link] (1 responses)

> Oh no, they claim it's public, but when you try to read them, the policies are also closed behind a login wall. :(

Nice way to collect passwords:-)

Authorities have responsibilities too

Posted Aug 10, 2026 3:43 UTC (Mon) by willy (subscriber, #9762) [Link]

... but you have to change it every 90 days ...

passwd -e

Posted Aug 7, 2026 21:35 UTC (Fri) by TomH (subscriber, #56149) [Link] (1 responses)

Whilst I agreed that time based expiry is bad I do hope passwd -e isn't going away... I regularly use that after I've set/reset a password for somebody to force them to change it on next login.

passwd -e

Posted Aug 7, 2026 21:50 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

I've been thinking about this precise use case.

Since event-based password expiry is legitimate, we must make sure to keep support for it.

This is a case of event-based password expiry (the event being in this case that you know the password).

The password expiry feature has expired!

Posted Aug 7, 2026 23:09 UTC (Fri) by hailfinger (subscriber, #76962) [Link] (8 responses)

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

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

By the way, if you're at the receiving end of a pointless password expiry policy, point the policy-setters to this NIST sentence:
> 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.
(If you'd like a voice from Europe, the German BSI has issued similar advice.)

Then, ask the policy-setters very nicely: "So.. when were you going to tell us that you were compromised?". I did that more than once and hey... it is a very effective conversation starter.

The password expiry feature has expired!

Posted Aug 7, 2026 23:37 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (3 responses)

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.
    [...]

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

The password expiry feature has expired!

Posted Aug 7, 2026 23:50 UTC (Fri) by mussell (subscriber, #170320) [Link] (2 responses)

What if those policy setters are the university that employs the authors of the paper that started this [0]? If they won't listen to their own faculty who they pay several hundred thousand dollars on, they won't listen to anyone else.

0: https://carleton.ca/secretariat/wp-content/uploads/sites/... Schedule B

Carleton University

Posted Aug 8, 2026 0:35 UTC (Sat) by alx.manpages (subscriber, #145117) [Link]

lol. That's certainly the next level. They have bonus points for requiring the sadly usual 1upper+1lower+1digit+1punct.

This university seems to be unaware of XKCD <https://xkcd.com/936/> apart from their own research. :D

The password expiry feature has expired!

Posted Aug 8, 2026 0:57 UTC (Sat) by dskoll (subscriber, #1630) [Link]

Haha, ironic that Carleton U's policy goes against what Carleton U researchers recommend. I hope they update the policy before 2028.

I received an M.Eng from Carleton University, actually, but in the Mesozoic era when there were no required passport expiries, no rules about password complexity, and telnet and rlogin ruled the roost for remote access.

The password expiry feature has expired!

Posted Aug 8, 2026 13:23 UTC (Sat) by grmnsftphr (subscriber, #178591) [Link]

I well remember the NIST pushing this nonsense of new passwords every few seconds at a time when all real experience experts were shouting from all rooftops how dangerous it is. Add in all the other NIST CVE slop long before AI security slop was a thing.

How to force a password change on next login

Posted Aug 8, 2026 13:50 UTC (Sat) by tchernobog (subscriber, #73595) [Link] (4 responses)

If this is getting deprecated:

> the third (date of last password change) [...] and the fifth (maximum password age)

What is the blessed way to force a change of password on the next login, in the case of accounts created with a default password by an administrator?

E.g. on embedded devices, there is often an "admin:admin" user where we set the max password age to 1 to enforce a change.

Other features related to ageing of password are probably fine to deprecate, but this one is very useful in my opinion for stock accounts.

How to force a password change on next login

Posted Aug 8, 2026 15:19 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (3 responses)

The exact deprecation notice in the release notes says:

.sp_lstchg: Restrict to just the values 0 and empty.

The value 0 is what forces a password change in the next login. The only two supported values will be 0 and empty (once that is done, in a few years).

How to force a password change on next login

Posted Aug 8, 2026 15:21 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (2 responses)

Here's what shadow(5) says now:

     date of last password change
         The date of the last password change, expressed as the number of days
         since 1970-01-01 00:00:00 UTC.

         The value 0 indicates that the user must change their password the
         next time they log in to the system.

         An empty field means that password aging features are disabled.

How to force a password change on next login

Posted Aug 10, 2026 15:28 UTC (Mon) by LionsPhil (subscriber, #121073) [Link] (1 responses)

Does that go for the account expiry date as well? (I see downthread that you're busy enjoying ripping out date-handling code in general.)

Particularly pointing to passwd(1) --lock and its suggestion of usermod(8) --expiredate as the way to actually disable a user account in a world of non-password login methods like SSH keys.

How to force a password change on next login

Posted Aug 10, 2026 16:44 UTC (Mon) by alx.manpages (subscriber, #145117) [Link]

The date of account expiry is documented in shadow(5) as the 8th field.

That field is not deprecated.

I wish we could get rid of all date-handling code, but a little bit remains. Certainly simpler than it once was, though.

Someone should make the point to these agencies

Posted Aug 9, 2026 16:07 UTC (Sun) by koverstreet (subscriber, #4296) [Link] (4 responses)

"Working with upstream and the community" is something that ought to apply to them, too :)

A lot of the security recommendations that get audited for compliance are of pretty dubious value, often outdated and counterproductive; the underlying issues tend to get fixed over time.

The regulatory agencies may not (don't) have engineering staff to be involved with fixing the issues, but I think there's a strong case to be made that if they're making broad policy recommendations on how to configure system X there needs to be open lines of communication between them and the system X maintainers. Productive development tends to come from good communication with users, and we've got tools they can use; bug trackers for tracking bugs, mailing lists, et cetera.

And as a maintainer, if someone out there is making wonky recommendations on how to use my code, I certainly want to be in the loop! Cuts down on the "you're holding it wrong" bug reports :)

It might be useful for projects like shadowutils to make up a public list of regulatory policies that apply to shadowutils with comments on "does this still make sense, or is it out of date with the promulgators AWOL" - it sounds like you're making that list anyways, just throw it up on the website where users can find it.

Sort of a reverse "auditing the auditors". And if there's something semi official up from the experts, it might give the actual users leverage to push back on nuttier policy.

We're probably going to be seeing the intersection of open source maintainers and regulatory policy only increase - c.f. all the age verification laws popping up. We the experts on the technology should probably be making our positions known and explaining the reasoning in language they can understand, rather than just adding whatever crap the regulators dream up.

Someone should make the point to these agencies

Posted Aug 9, 2026 16:45 UTC (Sun) by kleptog (subscriber, #1183) [Link] (3 responses)

> The regulatory agencies may not (don't) have engineering staff to be involved with fixing the issues, but I think there's a strong case to be made that if they're making broad policy recommendations on how to configure system X there needs to be open lines of communication between them and the system X maintainers.

Well sure. Regulatory agencies have many mechanisms for providing input: working groups, requests for comment, etc. They however are not going to proactively approach developers. If you think an agency is doing something that affects your project it's up to you to lobby, or find someone to do it for you.

In the specific case of the Spanish CNI, they're apparently an intelligence agency so by their nature not very open, so they're not a good example here. But at EU level you have ENISA which is much more open. Someone should probably send CNI a note that ENISA moved on from password expiry and they should follow suit.

You're not going to get into ENISA as an individual developer though, but organisations like OpenSSF and Apache/Eclipse foundation as well as businesses like RedHat/Canonical have an interest in representing open source projects. I think open-source as a whole does a decent job of lobbying (see the efforts around the CRA) but we're still on the reacting side. We're not yet at the point were the initial drafts of things take OSS into account.

> We're probably going to be seeing the intersection of open source maintainers and regulatory policy only increase - c.f. all the age verification laws popping up. We the experts on the technology should probably be making our positions known and explaining the reasoning in language they can understand, rather than just adding whatever crap the regulators dream up.

ISTM that were doing an ok job. Sure, it might be nice if F/OSS was a bit more organised rather than relying on the goodwill of various tech groups/businesses/etc to represent them. But I think we're doing as well as can be expected given the type of people that that do F/OSS.

Someone should make the point to these agencies

Posted Aug 9, 2026 17:08 UTC (Sun) by koverstreet (subscriber, #4296) [Link] (2 responses)

> Well sure. Regulatory agencies have many mechanisms for providing input: working groups, requests for comment, etc. They however are not going to proactively approach developers. If you think an agency is doing something that affects your project it's up to you to lobby, or find someone to do it for you.

Are you sure they never do?

If they don't, then they're being lazy idiots. No matter what your job is, you can't expect everything to come to you, you have to seek things out sometimes, and if you're promulgating regulations on specific software packages without ever reaching out to say "hey, this is us at X, this is what we're doing and why, this is how to contact us", then that's sheer lazyness.

> ISTM that were doing an ok job. Sure, it might be nice if F/OSS was a bit more organised rather than relying on the goodwill of various tech groups/businesses/etc to represent them. But I think we're doing as well as can be expected given the type of people that that do F/OSS.

That sounds like a cop out :)

If you're the expert at something, part of your job is education so that knowledge doesn't die with you. F/OSS isn't a hobby underground thing anymore, we build and maintain the infrastructure the world runs on, so part of our job description is now education - if not ourselves personally, getting organized enough so that it happens.

And I personally avoid the word organization, because that calls to mind meetings and committees - i.e. places where work doesn't get done. It's more about recognizing good ideas and getting the ball rolling so it becomes something we as the OSS community culturally recognize as something worth doing.

You can do a lot with just the right sort of encouraging conversations here and there, and making stuff visible that you were doing already by making your notes presentable and public.

A big part of my job right now is just the documentation and test infrastructure version of this. I'm not spending a ton of time writing new bcachefs code right now, a lot of it has been documentation and test infrastructure and working with people in those areas so that hopefully someday it can just be the default expectation that those parts of the project, and people will pitch in and help out because they see me doing it instead of seeing it as shit work that no one else wants to do. And it seems to be working pretty well; point is, this job isn't just about writing code, and leaving stuff to the organizations you mentioned often results in stuff not getting done or getting done badly. There's just a lot that goes into having a functioning ecosystem.

Someone should make the point to these agencies

Posted Aug 9, 2026 19:01 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> If they don't, then they're being lazy idiots. No matter what your job is, you can't expect everything to come to you,

If "reaching out" is not part of an an agency's charter, then yes, by definition stuff is expected to come to you instead.

> F/OSS isn't a hobby underground thing anymore, we build and maintain the infrastructure the world runs on, so part of our job description is now education - if not ourselves personally, getting organized enough so that it happens.

...I'm sorry, but if you're not being paid, then by definition it is a hobby, and there is no "job" to have a "description". Much less placing any obligations on you whatsoever.

You know, the whole "This software is provided as-is, with no warranty whatsoever" shtick.

Someone should make the point to these agencies

Posted Aug 9, 2026 22:32 UTC (Sun) by alx.manpages (subscriber, #145117) [Link]

> ...I'm sorry, but if you're not being paid, then by definition it is a hobby, and there is no "job" to have a "description". Much less placing any obligations on you whatsoever.
>
> You know, the whole "This software is provided as-is, with no warranty whatsoever" shtick.

I'm certainly not going to do any boring work without being paid. If any user (actually, companies) are affected by policies and want me to teach them about those, and possibly centralize knowledge about known regulations of our software, I'm certainly open to consulting work, and of course, to being well paid for it.

And if intelligence agencies are affected by our software releases and they don't voluntarily come to us, they'll have to do more work, so it's in their interest to come to us and talk. If they don't, I don't give a ****. I'll keep having fun of having broken the (bad) scripts of an intelligence agency with a release.

More tricks

Posted Aug 10, 2026 8:03 UTC (Mon) by ibukanov (subscriber, #3942) [Link]

On one of projects I worked the password rotation policy was enforced together with checks for a lot of common tricks. Still people came up with tricks like altering the case of couple of letters or swapping parts of passwords. Nobody liked it including the management but they explicitly told this was forced by regulations.

Why not let the administrator decide?

Posted Aug 10, 2026 9:44 UTC (Mon) by epa (subscriber, #39769) [Link] (37 responses)

I hate forced password rotation as much as anyone else, but this move seems a bit mad. The "best practices" have altered, as the political sands shift and fashions change, and now the code to implement them has to be removed. Not because it's too much of a burden to maintain, but because somebody, somewhere, has decided this is now the wrong way to configure your system. That decision is just as opaque as the original decision that passwords should be expired periodically. But shadow-utils never forced an administrator to set up password expiration; it only provided the tools to do so, if the sysadmin so chose.

Whether you personally support or oppose password expiration, it's reasonable to suppose that some organizations will have different requirements and make a different choice. And it's not something where you can definitively show a particular choice is wrong (unlike, say, DES password hashing, where you can show that it's easy to crack nowadays). It's not like an Internet RFC, where your implementation has to follow the MUSTs and MUST NOTs in order to work well with others.

The LWN article itself suffers a bit from this omniscient-voice attitude: "Some outdated policies still require password expiration. These policies, which are even required by some countries, are unfortunate." That seems to imply that the USA's NIST must be correct (even though it was wrong previously) and these other countries' policies must be wrong, though they may see the light eventually (as long as NIST hasn't changed its best practices again by then).

I don't want this to turn into one of those cranky systemd posts, but wouldn't it be better to have the infrastructure be mostly policy-neutral, and let the admin decide? At least if the support for expiration is already there and working.

Why not let the administrator decide?

Posted Aug 10, 2026 10:31 UTC (Mon) by mb (subscriber, #50428) [Link] (31 responses)

And it's not something where you can definitively show a particular choice is wrong

Yes, it is. And it's quite obvious that it is. Everybody and their dog knows that if password expiration is in place all people come up with their own ways to handle it that actually make the password less secure in many cases. I do it. Everybody does it. This is simply not possible in any other way. Nobody can remember 20 new strong passwords every 3 months. That's not how brains and muscle memory work for almost all people.

And besides that there's basically no case where password expiry would even help to improve things. If an attacker knows the password, game is over already. Immediately. It does not help at all, if the password is changed a month later (or even on the same day), because the attacker already had access and could do anything, including to establish a second channel to get in. If an attacker managed to steal a password then it clearly is not enough to just change the password and be done.

A password only has two states: It's secret or it's not. Expiry does not improve any of these states.

So, yes. Password expiry very clearly is wrong.

And if a company still insists on having this misfeature, they can easily maintain their own version of shadow-utils.

Why not let the administrator decide?

Posted Aug 10, 2026 15:59 UTC (Mon) by donald.buczek (subscriber, #112892) [Link] (15 responses)

Nobody can remember 20 new strong passwords every 3 months.

My password manager can.

Why not let the administrator decide?

Posted Aug 10, 2026 18:51 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> My password manager can.

Does that help if it is a login password? You need to login first to be able to get to your password manager and your corporate policies may not allow using it from say your mobile.

Why not let the administrator decide?

Posted Aug 10, 2026 20:48 UTC (Mon) by mb (subscriber, #50428) [Link] (13 responses)

Not all passwords can be fetched from password managers on use. Like login passwords, the password manager's password itself, or any other password that needs to be typed in all the time (going to the password manager 100 times a day is impractical).

I have about 10 passwords which I have to remember for various reasons. Unfortunately some of them have relatively short expiry and to make it worse some of them even have conflicting character rules and new-after-expiry-rules.

So, no. In these cases a password manager doesn't help at all. Only getting rid of expiry helps.

And while we are at it get rid of stupid character rules as well. A password does not get noticeably better by forcing the user to add numbers, because that will just make them put a 1 at the end.

Why not let the administrator decide?

Posted Aug 11, 2026 8:22 UTC (Tue) by geert (subscriber, #98403) [Link] (1 responses)

The really annoying character rules are the ones that insist on the presence of special characters, but reject half of the common special characters. So it takes a lot of cycling through "generate password" in your password manager until you end up with one that is accepted.

Why not let the administrator decide?

Posted Aug 11, 2026 9:02 UTC (Tue) by alx.manpages (subscriber, #145117) [Link]

I do something that so far has worked:

1). Generate a random password consisting of 64 [:album:] with `makepasswd --chars 64`.

2). If the system requires a symbol, I delete the last character, and replace it with a `+`. The choice of `+` is for a reason: when double-clicking the password, the `+` is considered part of the word, and thus I don't need to carefully select the characters.

3). In the rare case where `+` is not accepted as a symbol (happened to me last week, but it's very unusual), I replace it with some other symbol from the list of accepted symbols.

It's still annoying, and certainly doesn't make the password stronger, of course.

Why not let the administrator decide?

Posted Aug 11, 2026 9:12 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (3 responses)

> or any other password that needs to be typed in all the time (going to the password manager 100 times a day is impractical).

Have you tried pass(1)? I use it even for passwords that I use (quite possibly) 100 times a day. It stores my SSH key passphrase, for example, and I have configured ssh(1) to read it from pass(1). Being a command, which prints to stdout (or clipboard, with -c), it's easy to set up programs to use it, and use it 100 times a day if necessary.

> And while we are at it get rid of stupid character rules as well. A password does not get noticeably better by forcing the user to add numbers, because that will just make them put a 1 at the end.

I wanted to do this some time ago, but found some reticence (IIRC, the same reasons; that is, users forced by regulations). However, seeing that this seems to be working and that regulators will be forced to change, it seems we can probably also do that. I don't remember the exact rules we have for what is a complex password in shadow-utils (they are of course optional).

Why not let the administrator decide?

Posted Aug 11, 2026 9:45 UTC (Tue) by mb (subscriber, #50428) [Link]

Have you tried pass(1)?

I use my own password manager (https://github.com/mbuesch/pwman) since ages. It is command line and fully scriptable and pluggable into other apps that support this kind of thing. With ssh this might work. But with many other applications it doesn't (e.g. they have a GUI entry field only). So yeah, we might come down from 10 to 9 passwords that I absolutely have to remember.

I also do not want to unlock my pw database all the time, because that means I will have to frequently type in the most precious master password I have (people/cameras might see it). And it means that I have to decrypt all my passwords from the database into memory all the time (that's how it currently works. I have plans to fix this, but don't hold your breath), even if I just want to ssh into an raspberry-pi on my floor I unlock the keys to my whole life. And opening the password manager takes more time than usual, because the password is complex and the KDF is hard. I think the only options are remembering a dozen of main passwords or eventually use passkeys if everything supports this within the next three decades.

stupid character rules

I wanted to do this some time ago

Cool :)

Why not let the administrator decide?

Posted Aug 11, 2026 14:10 UTC (Tue) by Wol (subscriber, #4433) [Link]

Crazy idea, but might make administrators think ...

All of these stupid rules like "one special char, one number, etc etc", as you process and encrypt the password look for how many passwords suffer from them. Okay, you're going to get a few, but if you notice rather more than average, start downrating the strength of the passwords that match these rules.

You just want a mini database (plain text file) that says "x password changes, n complied with this stupid rule, o with that stupid rule, p with the other stupid rule", this isn't random, start complaining about passwords that match them. No need for the file to identify *which* stupid rule ...

At which point, any administrator who says "you need a strong password containing one special character, one number, one upper case, blah blah blah" is going to have the users coming back to them and saying "every time I try to follow the rules, the computer complains it's a weak password!".

Cheers,
Wol

Why not let the administrator decide?

Posted Aug 19, 2026 17:43 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

i love pass. I also implemented support for calling it from trabucco so I can get a password in the copy buffer without using a shell of I need to paste it somewhere.

Why not let the administrator decide?

Posted Aug 11, 2026 15:52 UTC (Tue) by farnz (subscriber, #17727) [Link] (6 responses)

And while we are at it get rid of stupid character rules as well. A password does not get noticeably better by forcing the user to add numbers, because that will just make them put a 1 at the end.

It feels like the end point we're reaching towards is a human-friendly entropy estimator for passwords: roughly how long would it take a sophisticated password cracking tool to guess this password?

The entropy of "SzEp1r03G" (9 random characters, with 62 choices for each character, chosen by my computer's random number generator, so just under 54 bits of entropy) is similar to the entropy of a 4 Diceware word password such as "WrongnessPopulatePastorEclipse" (7776 words in a Diceware dictionary, 4 words, so just under 52 bits of entropy), and both passwords should thus be as acceptable (or unacceptable) to a systems administrator; a cracker who knows the exact algorithm used in both cases will take about the same amount of time to guess both passwords, whereas "lwn.net1998" is very easy to crack if you know the algorithm (domain name and date of founding for the site - extends nicely as an algorithm across many sites, but takes 1 guess per site).

The hard question is how to implement such an entropy estimator. I can estimate entropy for passwords I create algorithmically (since I can do the log2(possible choices) * number of choices made calculation) very easily, but shadow-utils won't know how the user created the password, and will need to make a guess about how hard it'll be for a password cracker to brute force the password.

Why not let the administrator decide?

Posted Aug 11, 2026 16:02 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (5 responses)

> The hard question is how to implement such an entropy estimator.

I don't think password validators should concern about entropy. Users should use password generators, and those know the entropy of what they generate. The validators should just accept that users know what they're doing (or that at least, they should know).

If the admin wants their users to have strong passwords, it should point them to password generators, or at most, require a minimum length. More than that is experimentally known to be useless, or even detrimental.

Why not let the administrator decide?

Posted Aug 11, 2026 16:39 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

If you're trying to make passwords secure, you end up needing an entropy estimate in order to be able to detect users who are lying to you - they claim to use a password generator, but do things like "tweak" the generated password to be more memorable (so they change "swxjzdap", which is generated by an 8 character, 26 choices per character ⇒ 37 bits entropy, to "sexizdad" for memorability).

Note that a minimum length is a weak entropy estimate - you know that written text has an entropy around 1 bit per character in most alphabetical languages, so you know that a minimum length of 10 characters is going to be 10 or more bits of entropy.

Ultimately, though, while it's fun to think about how to make passwords secure, we already know how to do far better - key based authentication (like SSH keys) means that you've got as many bits as you want for the authenticate to a system approach (a 256 bit ECDSA SSH key is equivalent to a 10 word Diceware passphrase, or 22 characters of random case-sensitive letters and numbers), and you can have a master key backed by a hardware token to give you 2FA for unlocking access to your keys (with, again, the large number of bits a key can have).

Why not let the administrator decide?

Posted Aug 11, 2026 16:51 UTC (Tue) by mb (subscriber, #50428) [Link] (1 responses)

we already know how to do far better - key based authentication (like SSH keys)

These only solve part of the problem. If done properly then they still need a (local) password. Otherwise they are as insecure as storing your password database as passwords.txt on the local disk.

Why not let the administrator decide?

Posted Aug 11, 2026 18:38 UTC (Tue) by farnz (subscriber, #17727) [Link]

Even a strong password that's stored in ~/passwords.txt on my local disk is a significant security upgrade on a weak password on a networked system. Attacking a system that deliberately lets you log in over the network is significantly simpler than getting a copy of a file on my local disk.

And the admin can't guarantee that I'm not doing something stupid - I did point out that you can have the keys stored in a key manager that requires a hardware token to unlock (modern password managers can act as SSH agents, for example, requiring a hardware token to unlock the password manager). But making the attacker attack my system to get my account, rather than opening up attacks like "crack the password someone uses on MySpace, transform it and use it to log into your system" is a worthwhile endeavour.

Why not let the administrator decide?

Posted Aug 11, 2026 16:45 UTC (Tue) by mb (subscriber, #50428) [Link] (1 responses)

If the admin wants their users to have strong passwords, it should point them to password generators

Well, yes and no.

If the generator generates truly random passwords then: No. This only works, if the password does never have to be remembered. This does not work for many passwords that matter like main login passwords or password manager main passwords.
If the generator generates these readable random passwords (like pwgen (1)) then: Maybe. They are still kind of hard to remember and therefore risk being short or written down on Post-Its.
If the generator generates long xkcd-936 style passwords then: Yes. Is there a generator with a big enough word database that can do this?

The most important thing and at the same time the hardest thing is to get the old and counterproductive rules out of people's heads. There are rules like "8 chars are enough", "passwords must be as complicated as possible" or "no words from the dictionary" that truly hurt security, but are buried deep in peoples heads. I have no idea how to do that easily, though. Unlearning is harder than learning. :)

Why not let the administrator decide?

Posted Aug 11, 2026 21:08 UTC (Tue) by alx.manpages (subscriber, #145117) [Link]

If the generator generates long xkcd-936 style passwords then: Yes. Is there a generator with a big enough word database that can do this?

There is. :)

$ whatis xkcdpass
xkcdpass (1)         - generate memorable, secure multiword passphrases

https://manpages.debian.org/buster/xkcdpass/xkcdpass.1.en.html

I have no idea how to do that easily, though.

We can have a mention in the manual page of passwd(1). It isn't great, but that's as much as I can do.

Why not let the administrator decide?

Posted Aug 11, 2026 17:19 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (14 responses)

Ultimately, I think this mostly highlights that passwords on their own just don't cut it anymore. Available cracking power has grown radically faster than human brain power, which means the kinds of passwords people are willing and able to memorize just aren't up to the task. Rather than trying to convince people to memorize and type ever more challenging passwords, we need to move to some kind of 2FA for anything that requires real security. It's not like this is radically new tech; hardware tokens have been around for decades. We need to officially limit password-only authentication to low security applications.

Physically secured versus low security

Posted Aug 12, 2026 11:09 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

Note that to make this a workable position, you need to account for physical security as part of "authentication"; while I authenticate to a server console with just a password, that's OK because physical access to that server is secured, and no-one can get physical access to the server. From one perspective, this is password-only authentication (since all the digital side can see is a password), but from a wider perspective, it's password + physical access.

Otherwise, you end up risking a silly loop - my Yubikey (for example) only authenticates me by a password, which can imply that use of the Yubikey for U2F is a "low security application" since it's password-only authentication to the Yubikey.

Physically secured versus low security

Posted Aug 12, 2026 17:11 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Note that to make this a workable position, you need to account for physical security as part of "authentication"

Absolutely. If you have good physical security and can distinguish someone logging in locally from someone coming in over a network, it completely makes sense to treat being physically present as a form of authentication. My employer does something like that. We nominally require 2FA for everything, but if you're detected to be on-site, the step where you have to produce a time-based authentication code is skipped.

Otherwise, you end up risking a silly loop - my Yubikey (for example) only authenticates me by a password, which can imply that use of the Yubikey for U2F is a "low security application" since it's password-only authentication to the Yubikey.

Possessing a physical device and knowing a password is a classic example of 2FA. Forms of authentication that people usually talk about are something you have (like a physical token), something you know (like a password), and something you are (i.e. a biometric). The idea with 2FA is that you require two different categories so someone who wants to compromise your security needs to overcome two different kinds of obstacle. For example, your Yubikey still counts because someone who wants to bypass your security needs to learn your password and get physical access to your key.

Physically secured versus low security

Posted Aug 13, 2026 9:03 UTC (Thu) by farnz (subscriber, #17727) [Link]

Possessing a physical device and knowing a password is a classic example of 2FA. Forms of authentication that people usually talk about are something you have (like a physical token), something you know (like a password), and something you are (i.e. a biometric). The idea with 2FA is that you require two different categories so someone who wants to compromise your security needs to overcome two different kinds of obstacle. For example, your Yubikey still counts because someone who wants to bypass your security needs to learn your password and get physical access to your key.

Indeed; but if you ignore the physical security aspect, my Yubikey protected by a password and my actual password boils down to just two passwords, and if we're saying that passwords are only for low security applications, that's just two methods only suitable for low security applications.

The thing that makes my Yubikey a useful second factor is that the physical security of my Yubikey is good enough for the applications I have for it (it lives with my keys, and I cannot go 24 hours without noticing if it's gone missing as a result); in practice, therefore, the Yubikey is a second factor because of the physical security.

Similar thoughts apply to a strong password written down on a note in my wallet - yes, that's "less secure" than the same password memorized, but it's a heck of a lot more secure than a Google employee using "Google1600 AmphitheatreParkwayMountainViewCA94043" as a "memorable" password (company name and HQ location).

Why not let the administrator decide?

Posted Aug 12, 2026 14:31 UTC (Wed) by ebiederm (subscriber, #35028) [Link] (5 responses)

I don't think it is this simple. Memory hard hash algorithms limit what kind of computers can even try to guess your password, and limit how fast guesses can be made.

My experiments with random passphrases tell me that 6 random words are doable. With a word list of rougly 65536 words this is enough for 16 bits of entropy per word and 96 bits of entropy total.

That said you don't want to use a password like that for anything except local access to a device right in front of you because a high entropy password is difficult to hard to memorize.

Why not let the administrator decide?

Posted Aug 12, 2026 15:01 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

Note for context that it's trivially easy to get more than 128 bits of entropy with key-based authentication methods.

That's why it's probably time to retire passwords - something very hard to memorise is weaker than a low quality key; so for network use, the key is more useful, and for local access, you're fine with better physical security and a weaker (⇒ easier to memorize) password.

Why not let the administrator decide?

Posted Aug 12, 2026 16:07 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

Maybe this is a controversial opinion, but for local access, I think it's fine to pick a very strong password that you then write down and keep on a card in your wallet.

We are all very familiar with physically securing our wallet, so I don't see much danger in doing this. Of course, if you lose your wallet, it's a problem, so make sure you have written it down somewhere else safe so you can go in and change it if necessary.

But even if someone finds your wallet and password, they still have to know which system the password is for and gain physical access to that system.

Why not let the administrator decide?

Posted Aug 12, 2026 16:46 UTC (Wed) by farnz (subscriber, #17727) [Link]

I would agree with you - I think the opposition to writing down passwords stems, very fundamentally, from "one size fits all" security thinking, with a sprinkling of "I am immune to the $10 wrench attack".

In the end, your authentication method only has to be good enough to force attackers to either give up, or escalate to an attack where you will give them your authentication credentials in the hope of avoiding whatever consequence you're threatened with for not giving them up. If you're going to be quick enough to notice that the written-down password has left your wallet and trigger a password change when that happens, then writing it down is fine unless what we're talking about is something like the password needed to trigger global thermonuclear war (a strange game).

After all, if someone is in a position to get away with murdering me, I'd rather give them my credentials (including hardware tokens, not just passwords) than die, and I don't think I'm that unusual in feeling that way.

Why not let the administrator decide?

Posted Aug 12, 2026 23:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Also note that what you write down doesn't need to be the password. It can be rot13'd, embedded as every Nth (or f(n)th where f is something like the prime counting function or the like) character of a larger string.

Why not let the administrator decide?

Posted Aug 12, 2026 17:27 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

I'm exaggerating for sake of emphasis. Yes, for critical applications we can probably create and memorize passwords that are sufficiently difficult for a machine to crack that they are secure in practice, but that still depends on everyone who uses the system being willing and able to make and memorize that kind of password. One of the lessons we should have learned from password expiration is that making the system harder just gives people an incentive to try to cheat, undermining the supposed benefits. If passwords are too hard to create and memorize, and people will cheat the system by repeating the same word 6 times or something similar.

Another important point is that depending on a harder password still leaves that password as a single point of failure. It's still vulnerable to phishing, mistakes that leave it unencrypted somewhere, and all the other non-cracking ways we've seen passwords fail over the years. 2FA gives you some redundancy against those kinds of failure.

Why not let the administrator decide?

Posted Aug 12, 2026 17:37 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

> which means the kinds of passwords people are willing and able to memorize just aren't up to the task.

??? My company mandates a minimum length of 16 characters, which in me at least inspires some creative (and easy to remember) passwords.

"OwlDollyClipperForTwo"

I think that would be rather difficult for a computer to crack? And even for somebody who knows me, well the owl is obvious, Dolly is our cat, and then the train of thought goes veering off deeply into Edward Lear or Lewis Carroll country. Dead easy for me to remember, five random words stuck together makes it hard for a computer, and even for a good social engineering attack it's wandered seriously off track after the first two words ...

As for my real password at work, my biggest problem isn't remembering it, it's not making silly typos half way through!

(I'm not using this as an argument against defence in depth, though ...)

Cheers,
Wol

Why not let the administrator decide?

Posted Aug 12, 2026 20:33 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

My company mandates a minimum length of 16 characters, which in me at least inspires some creative (and easy to remember) passwords.

I agree there are some ways of making longer passwords that are still easy to remember. For example, my work password expresses just what I think of my employer's password policy, which makes it easier to remember when it's time to type it. The problem is with the "in me at least" part, because you have to get everyone on board for it to work. Getting into a system is a weakest link type of thing, so it only takes a few people who pick easy passwords to undo the benefits of whatever clever password policy you choose. Meanwhile, 2FA gives you better security than most of the passwords real users are likely to pick and resistance to other kinds of attacks, like phishing. Oh, and users can't easily bypass the need for 2FA the same way they can undermine strong password policies.

Why not let the administrator decide?

Posted Aug 12, 2026 21:22 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

>my work password expresses just what I think of my employer's password policy,

Sounds like we have the same password :)

Why not let the administrator decide?

Posted Aug 12, 2026 21:15 UTC (Wed) by dskoll (subscriber, #1630) [Link]

My personal password rule is: My login password must begin with /.

Can you figure out why? 🙂

I once typed the password into what I thought was a locked screen but was actually an IRC client. Thankfully, most chat programs have continued the tradition of using / to start a command.

Why not let the administrator decide?

Posted Aug 13, 2026 8:56 UTC (Thu) by farnz (subscriber, #17727) [Link]

That's roughly 100 bits of entropy - all 5 words in your password are in /usr/share/dict/words on my system, and that file has a bit under 2¹⁹ entries, plus adding a few bits to allow for the fact that capitalized dictionary words is not the only option here.

Why not let the administrator decide?

Posted Aug 10, 2026 10:40 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (3 responses)

> Not because it's too much of a burden to maintain,

Are you sure? It *is* much of a burden, IMO.

The patch set that removed the expiry(1) program is +2/-2916. The patch set that removed .sp_min is +24/-1241.

The draft patch set that will remove the rest of password aging is going to remove 19.5k lines of text (including source code, tests, docs, ...).

And prior to this, we already significantly reduced related features, such as the allowed date formats, since parsing dates is really hard. Just in source code, we've removed thousands of lines of code, and will remove hundreds more.

Handling of dates is hard. We've had to fix a large number of bugs in that code (including integer overflows) in the recent years.

> and now the code to implement them has to be removed.

That's the nicest part. That includes removing some of the ugliest code we have in the project. Adding dates is something "interesting", which I'm happy to not need to do anymore.

> That decision is just as opaque as the original decision that passwords should be expired periodically.

I believe linking to scientific research that shows that password expiration provides no tangible benefits is not being opaque. I invite you to read that paper thoroughly: <https://people.scs.carleton.ca/~paulv/papers/expiration-a...>.

> wouldn't it be better to have the infrastructure be mostly policy-neutral, and let the admin decide? At least if the support for expiration is already there and working.

Support for expiration is already there, but "working" is probably too much to say about it.

Why not let the administrator decide?

Posted Aug 10, 2026 11:05 UTC (Mon) by epa (subscriber, #39769) [Link] (2 responses)

Thanks for the explanation -- it does sound like a useful cleanup.

I don't disagree that forced password rotation is usually a bad idea. But it was a bad idea ten years ago too. Some organizations implemented it, not because they had decided for themselves that it was useful, but because policies and "best practices" mandated it. In some countries those policies still exist, so password rotation may still be needed, even though it's still just as useless as it was a decade ago.

I think the change could better have been framed as "this is a lot of crusty code, which previously had to be there because policies mandated it, even though everyone agrees it's a silly idea -- and now the policies have changed we can finally remove it".

Why not let the administrator decide?

Posted Aug 10, 2026 11:42 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> Thanks for the explanation -- it does sound like a useful cleanup.

:-)

> But it was a bad idea ten years ago too.

Research still didn't exist. While it was known it was bad, scientific research is relatively recent. Also, considering that science takes time, it's reasonable to let some years pass until some scientific research is considered solid.

Another thing is that I wasn't maintaining shadow-utils 10 years ago. :)

> I think the change could better have been framed as "this is a lot of crusty code, which previously had to be there because policies mandated it, even though everyone agrees it's a silly idea -- and now the policies have changed we can finally remove it".

A problem is that most policies still have not changed (including the one from my country). If we waited for that to happen first, I expect we couldn't remove the code in this century.

This change is more in the lines of forcing policies to change. This is more or less the frame:

"""
Password expiration is undoubtedly bad, and since the code is really hard to maintain, we don't feel like doing that anymore. Existing policies are immediately coerced into removing password expiration, and if they don't, they'll have to 1) start looking for other software (or fork), and 2) start justifying their existence (or users will start complaining seriously).

We'll provide a grace period of a few (unspecified) years, but it might be as short as 1 year or 2. That's essentially the time it will take us to review these patches carefully.
"""

Why not let the administrator decide?

Posted Aug 10, 2026 16:27 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

A problem is that most policies still have not changed (including the one from my country).

And even in places where the official recommendation has changed, a lot of the organizational policies haven't caught up. My USA-based employer is still requiring password rotation even though our government now says it's a bad idea. We all know it takes a long time for best practices to move from the bleeding edge to common use, so it's no surprise that best security practices are the same way. Using technology to force those best practices is an interesting approach.

Why not let the administrator decide?

Posted Aug 10, 2026 11:00 UTC (Mon) by farnz (subscriber, #17727) [Link]

This is more than just "best practices" altering; in the time interval between the "best practice" of password expiry being written down, and today, it's been empirically studied and theoretically analyzed, showing that the best practice neither improves security nor has the effect it is intended to have (as explained in the rationale for the best practice).

Given that the rationale for the best practice is disproved by reality, and that it's a non-trivial piece of code (as it involves date handling, which is inherently non-trivial), it's almost certainly the case that it makes the maintainer's life hugely simpler if it's removed.

And note that because event-based expiry (where an external event tells the system that your password is expired) still exists, anyone who does need a time-based policy can implement the time-based part externally, and trigger an expiration event at the appropriate time. That is more maintenance burden for them - but they're the people who want a feature that has non-trivial maintenance burdens and where research says it's a net-negative, not a positive feature.

PCI DSS

Posted Aug 13, 2026 8:21 UTC (Thu) by XTerminator (subscriber, #59581) [Link] (1 responses)

Nobody mentioned PCI DSS, and of course my intention is not to start a 'this xyz standard also' but regardless of what some other standards institutes have found, or it being secure or not secure, as a company taking card payments we have to comply with PCI DSS standards and are frequently audited (at least once a year)....

So if shadow-utils won't provide these time based expiry anymore our company and probably 10 million billion other companies will start to do their own password timeout and rotation scripts

Or, I may just fork the shadow-utils

either way, just another pain in the proverbial rear passage, that with the ever reducing max age of certificates that can't be managed through automation :-(

PCI DSS

Posted Aug 13, 2026 9:37 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

For now, periodic password expiry is still supported; only deprecated.

The first removal only removed minimum password age, which AFAIK, no regulation mandates. IIRC, I did check PCI DSS some time ago, and it doesn't mandate it, right?

Auditors may complain about the lack of minimum password age, since that allows users to workaround password expiration policies, but you should complain to auditors saying that not allowing changing a password immediately is itself a security problem: if someone sees you while typing the new password, you should immediately change it (even if the age of that password is effectively 10 seconds), and you should also complain that the regulation doesn't require that. If the auditor doesn't recognize the security problem of not allowing 0-day password changes, you should report the incompetence of the auditor to the regulator.

Once that happens, please come to shadow-utils, and let us know the result of that litigation.

You would also do well pointing to this removal (and the deprecations that will be eventually removed in the future) to the authors of PCI-DSS, so that they decide whether they still believe in periodic password expiry or they want to accept it's bad.

If regulators are open to talk about removing this, and they need X years (such as maybe 5), we're open to slowing down on the removal, to reduce the friction.

If regulators on the other hand ignore this and refuse to talk, we're going to unilaterally remove this, eventually.

Also, we're not going to start conversations with every regulator. I tried to start conversations with the only regulator I know in my country. But users affected by other regulators (e.g., you by PCI-DSS) should talk to them. Please point them to this publication, and to the shadow-utils release notes.