sudo-rs
sudo-rs copied to clipboard
memorysafety
Enable pwfeedback (show asterisks) by default
Since sudo-rs is a modern sudo implementation written in a sane modern language (🦀❤️), perhaps it should make sane modern UX decisions.
Not showing asterisks as you type your password is one of the most hilariously bad UX decisions ever made. I propose that sudo-rs should just change the default for pwfeedback to true.
What about backwards compatibility?
It's a change in default behaviour but it shouldn't actually break compatibility with any other tools because no other tools depend on sudo not printing asterisks by default, or would be broken by changing it so that it does print asterisks.
What about security?
There's no practical security advantage to not printing asterisks. Virtually no other password entry systems work like this, and I have never heard of a single case of a password being broken merely by being able to see it being entered. Even knowing the length is less useful than you might think (I can explain if necessary).
Shouldn't distros do this?
The amount of work to convince the N most popular distros to do this would be astronomical. Furthermore they seem unable to see sense. See this Ubuntu bug which has been open since 2008!! Here are the most interesting comments:
1st report:
I'm reading a lot of forum postings and every other day someone with little experience in linux and shell commands asks the question [why is sudo broken?]
So please could you add a little sentence, that you can't see asteriks or your password while entering your sudo password.
Voice of reason:
Instead of trying to explain the problem, why not fix it, by getting sudo to show asterisks as you type your password?
Someone makes the very good point that plenty of other password interfaces in the Linux world show asterisks:
If it's not safe to show the length of a password, then sudo and gksu and PolicyKit should explain that your typing won't be shown, and all of them should provide alternative feedback (e.g. showing a momentary symbol each time you press a key).
This is why it has to be fixed here - distros will refuse to do it:
A distributor should never ever patch such important packages like sudo
Forwarded upstream, will discuss it there first.
Upstream rejected this, and carrying a patch eternally in such a sensitive program is really bad.
...
I reopen here. Today we had on ubuntuusers.de THREE new user who asked how they can enter their password inside a shell. All of them thought their keyboard was defect...
This comment is gold:
This is definitely not a paper cut, as average users will never open a terminal, and therefore never use sudo.
The discussion continued fruitlessly for a couple of years until apparently everyone gave up. The final objection was:
we feel sudo password feedback on the server is undesirable since it introduces an avenue to enumerate the password length where one did not exist before.
That doesn't make sense for lots of reasons (password length isn't very useful for cracking, if an attacker can read your sudo output somehow it's probably game over already, etc.).
Can't users just configure this themselves if they want?
No. This is an issue for people who haven't already learned about sudo's crazy default behaviour. Once they have most people just put up with it rather than figure out what arcane configuration they need to change to fix it.
In other words, this needs to be fixed by default. The default is the important thing here. It should be sensible. The paranoid minority should be the ones that have to go out of their way, not normal users.
Conclusion
Sorry that was a bit long. But my experience of trying to fix UX issues like this is that people instinctively get uncomfortable with change and synthesize all sorts of technically reasons why change is impossible so I wanted to head those off.
Also think of the great press you'll get on Phoronix :-D
Oh and I am willing to make a PR for this.
Lets make it a choice: default to true but still false can be a valid option. This is a missing feature for feature-parity anyways. However its a bit pointless and adds code & attack surface so its up to the maintainers to decide if effort needs to be spent on aesthetics right now.
Lets make it a choice: default to true but still false can be a valid option.
Yes, exactly what I meant.
This is a missing feature for feature-parity anyways. However its a bit pointless and adds code & attack surface so its up to the maintainers to decide if effort needs to be spent on aesthetics right now.
What do you mean? Support for the option seems to have been implemented already no?
I made a PR since it was trivial and now it's clear exactly what is being proposed.
On macOS the sudo password prompt shows an icon of a lock. Would that help with the UX issue?
I don't think so because a lock icon does not recognisably mean "you won't see any asterisks when you type your password". If anything I think that could be more confusing - is the password input locked somehow? Is that why I can't type in it?
In any case, communicating to the user why sudo has this confusing behaviour is always going to be worse than fixing the behaviour, which fortunately is very easy in this case!
I would be interested to see what @millert thinks about this.
Ever since pwfeedback was implemented on sudo-rs, I have it enabled and have to say I like it.
I added the pwfeedback option for people unused to the normal Unix method of echo being disabled for password entry. The default behavior is consistent with standard things like login, ssh, su, passwd, etc. This wasn't really a problem when sudo was only being used by sysadmins and power users--people who were used to how Unix works.
Now that sudo is the default way to become root on some systems (like Ubuntu), running sudo may be the first time many of these users run into a program that disables echo for password entry. I don't really object to enabling pwfeedback by default. I haven't decided whether to change the default on ogsudo; I suspect there would be some blowback from that change. Since sudo-rs is a rewrite, it is easier to change things like this.
During a team meeting, we decided to keep this issue open for now, so it may attract more feedback.
One the one hand, I would be likely to say "it's the distro's job to decide on this", but I think the original author makes some good arguments that the distro's in turn will be pointing back to us, and then nothing happens. And we also agree that the "it exposes the length of the password" argument is silly (if the password is so short that this reveals a useful amount of entropy of your password .. then your password is too short). Since we implemented pwfeedback we believe it can be enabled securely (cf. criteria for inclusion, nr.1)
A downside of changing this is that distro's that might like the default-pwfeedback-off behaviour would need to take action (either patching sudo-rs or patching the default /etc/sudoers file).