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

Why not let the administrator decide?

Posted Aug 11, 2026 17:19 UTC (Tue) by rgmoore (✭ supporter ✭, #75)
In reply to: Why not let the administrator decide? by mb
Parent article: Changes in shadow-utils password-expiration features

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.

to post comments

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.