Why not let the administrator decide? [LWN.net]

Why not let the administrator decide?

Posted Aug 10, 2026 10:31 UTC (Mon) by mb (subscriber, #50428)
In reply to: Why not let the administrator decide? by epa
Parent article: Changes in shadow-utils password-expiration features

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.

to post comments

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.