Entering password in Terminal gives no visual feedback

Agree, anything to reduce forum hits for new users.

Matthew, do you have a suggestion for concise and clear instructions for this? Thank you in advance!

How about a simple sentence:

--
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details. While you enter your password, you won't get any visual feedback.

foo@bar:~$
---

Hi,

Christoph Langner [2008-03-13 18:34 -0000]:
> To run a command as administrator (user "root"), use "sudo <command>".
> See "man sudo_root" for details. While you enter your password, you won't get any visual feedback.

I'd shuffle this a bit:

 To run a command as administrator (user "root"), use "sudo <command>"
 and enter your password (you won't get any visual feedback).
 See "man sudo_root" for details.

What do you think?

That looks good.

Instead of trying to explain the problem, why not fix it, by getting sudo to show asterisks as you type your password?

Matthew Paul Thomas [2008-03-14 3:36 -0000]:
> Instead of trying to explain the problem, why not fix it, by getting
> sudo to show asterisks as you type your password?

sudo is a pretty paranoid program, so it doesn't expose the length of
the password by showing asterisks.

Either it's safe to show the length of a password, or it isn't. If it is, this bug can be fixed by getting sudo to show asterisks. If it isn't, then it's a bug in gksu and PolicyKit that they show bullets.

Either way, I think the right place to fix this is in sudo itself, not in a terminal introduction that might be scrolled away into oblivion by the time you first use sudo. 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).

I don't see why asterisks should be a problem. If someone is able to see the asterisks on your screen he must stand behind or right next to you. So he would most likely be able to see your keyboard. And if he sees your keyboard, he wouldn't be interested in the length of the password since he would already know much more interesting information about the password (i.e. the raw "layout" of your password, if numbers are users, etc.).
Also he would be able to determine the length by simply counting the 'clicks' on your keyboard.

A distributor should never ever patch such important packages like sudo, even when the change might be small. So, either report your wish upstream or change the explanation message. But please, don't patch sudo!

Christoph Langner [2008-05-20 14:56 -0000]:
> A distributor should never ever patch such important packages like sudo,
> even when the change might be small. So, either report your wish
> upstream or change the explanation message. But please, don't patch
> sudo!

Patching security-critical infrastructure in distros should absolutely
be no problem at all! </dark sarcasm>

No, of course I'll discuss this upstream first. I tend to agree that
showing stars isn't too bad, although much worse than Blattlaus
argued: the stars remain on screen even after you typed it
(scrollback), etc. But if it wouldn't be stars, but rather something
like a random throbber, this would provide key press feedback without
giving away information about the length.

Forwarded upstream, will discuss it there first.

Upstream rejected this, and carrying a patch eternally in such a sensitive program is really bad.

Also, on a standard desktop you hardly have to use sudo on a Terminal anyway, thus "wontfix".

> Also, on a standard desktop you hardly have to use sudo on a Terminal anyway, thus "wontfix".

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... Please, can we get back to my first proposal. Don't patch sudo, only enhance the message which appears the first time, when you execute a command with sudo....

Changing the initial note to this works for me:

 To run a command as administrator (user "root"), use "sudo <command>"
 and enter your password (you won't get any visual feedback).
 See "man sudo_root" for details.

> Changing the initial note to this works for me

I don't think this would help, because most people don't read this message and even if the do, they won't remember that month later.

Upstream now added a "pwstars" option in cvs head, which will be released as 1.7.0.

Seems fixed Upstream , Just need to make it in sudo (Ubuntu)

This is definitely not a paper cut, as average users will never open a terminal, and therefore never use sudo.

> David Siegel This is definitely not a paper cut, as average users will never open a terminal, and therefore never use sudo.

That's where I don't agree. In Forum posts and Support sites etc, you find a lot of command-line commands, that you're advised to execute to install a certain package or just to execute something and post the output.
No visual feedback is just confusing.

I just don't see why its better to have no visual feedback.

Also when entering the pw when you login to a shell is not visible (not only sudo), and this gave me some trouble recently:
I had a problem with the graphic card driver and was in Textmode. Because of a problem with the driver or whatever, not every keystroke was accepted. I had to log in in text mode. for the username, I saw the characters, so i could retype a char if the keystroke wasn't accepted, but when entering the pw i had a real problem.

So, its not only useful for newbies

I feel some form of feedback is essential when entering the password. About the stars being visible after scroll back, what is wrong? The only thing that's possible would be just to know the length of the password. How will anyone with access to scroll back be able to find out what the password is by just viewing the stars/asterisks?

Also, this feedback should be added not just to the sudo command, but also when you ssh to a server, use scp and perhaps even when the shell login is done. I'm not saying feedback's essential in these cases. But feedback'd be good if it were present for these packages too that's all.

But, for sudo I feel the asterisks are needed because most linux forums that users seek help in depend on the use of CLI i.e. the sudo command rather than the gksudo command. So, it'd great if at least sudo got the asterisks and not any other form of feed back.

It's been long held unix tradition not to expose the length of passwords being entered. I don't think it's in any way sensible to degrade the security on every password entry just to avoid first-time confusion.

I absolutely agree with Max [22]. Moreover I'd slightly modify gksudo and login screen in this way.

My idea is to NOT expose pw length by any stars or whatever. BUT in all the cases sudo, gksudo and login screen show always only one char for indication (asterisk perhaps) which would almost immediately (300ms ?) disappear.

I think adding "warning text" [4] isn't bad idea, but you know people. ;) Mainly former Win users (Next -> Next -> Next -> OK). :D

I like Terminal not showing my password. Yes, this thing is called "Terminal". Windows has CMD, we have a Terminal, so I changed the title of this bug report.

In the old version of GDM was also an option to not give any visual feedback when entering the password and I always enabled this option.

In the new GDM this option isn't implemented (yet) and now people are also talking about showing the length of passwords in the Terminal. Why not put an option somewhere (maybe in Authorizations) called "Give graphical feedback when entering passwords"? When enabled (I think this should be the default behavior in order to not confuse new users), the length of the password is always shown (in GDM, in Terminal, when using gksu and in PolicyKit). When disabled (users like me, who want additional security can just remove the checkmark), the length of the password isn't shown (so in GDM, in Terminal, when using gksu and in PolicyKit no graphical feedback is shown).

I always liked the behavior of the Terminal and the option to disable the grahical feedback in GDM, but gksu and PolicyKit still showed the length of my password. Using one option which controls the graphical feedback of GDM, Terminal, gksu and Policykit will create one consistent behavior. The length of your password is shown everywhere or it's shown nowhere. Nowadays the behavior is completely inconsistent. One application doesn't show the length of your password (Terminal), while others always show the length of your password (gksu, PolicyKit, new GDM) and other have an option to disable the visual feedback (old GDM).

Patrick Roberts (#24) seems to have made the most valid conclusion. However, I agree with one modification: there should be an intermediary state to disable feedback only in the terminal and leave it on in other places. So, 3 states. Make the default state to be to show all password entry lengths. This really is a hugely preferential thing as far as I can tell, so just store a number (0, 1 or 2) in a file (like .pwentry) in the home folder that specifies what to do, with 0 being no feedback anywhere and 2 being feedback everywhere. If the file was missing, it would be assumed 2 and written to the file. Then System -> Preferences -> Appearance could have a combobox to switch between states.

Can anyone contest the simplicity of this? Or better yet, can anyone contest this plan? If not, its settled then; simplicity + functionality = a stable, usable UI.

#24 and #25 are spot on. As a relatively new-to-linux user, this is what I would expect and understand. One additional consideration might be to display the "explanation" message (#3, et al) AFTER 2 or 3 failed sudo attempts, or after 15 seconds, etc. This will likely cut down on the confusion while not making overt changes to the sudo "interface" for experienced users.
If an explanatory message is included, I would further propose that it includes the location of the combobox to change the star behavior.

Let's not discuss unrelated topics on this bug report.
Currently gksu, PolicyKit, new GDM do show feedback and the terminal is the odd one out here.
Adding a system-wide option is not what this bug report is about.
I dont believe there is an option in gksu, PolicyKit, new GDM to even disable the feedback. Kindly file bugs in the appropriate apps rather than discussing them here.
Only if they are fixed in the appropriate apps is the system wide setting even possible.

Terminal is now being fixed to show the starts by default. Once the other apps are fixed we can discuss about system-wide settings.

There is no "pwstars" option. Upstream just added support for using a helper program to read the password. This is not something I have time or motivation to write, especially not for an use case where the other half of users would cry out about changing the behaviour.

Then we're back at square one. What about my first proposal? Just add a couple of words to the message which explains that you won't get a feedback. People WILL read that, when they stumble upon this "problem".

I agree Christoph and it would be nice, if you can find there an easy way to fix this "Problem".

Well I think it's best to have a notification every time when the password is asked by sudo saying that no feedback will be given. I know I did say it'd be best to have stars but I actually like it when no feedback is given by terminal. I've created a patch for this. It prints the notification when the password is asked by sudo.

Here's a screenshot of the patch working in lucid alpha 1. Don't know why I couldn't attach it with the patch in the earlier comment.

Also, can someone tell me why it displays "Password: " instead of the usual "[sudo] Password for user: ". I tried to figure this out but no luck. Would be happy if someone would explain this to me.

There is decades-long precedent that the Unix commandline environment is terse by default. Your patch would provoke severe irritation in a huge userbase if applied.

Well then what could be a possible solution? Not many Ubuntu users will appreciate the fact that terminal will give a feedback such as stars (as many stated here) and not many new users will remember unless reminded about this just like what Blattlaus said in comment #16. Perhaps a timed reminder in interval of a few days or something?

hmm... interestingly enough, I remember something similar to this happening.
What was it? Oh yes, Ctrl-Alt-Backspace. Its been around for who knows how
long, yet it got disable recently in the default installation. However,
there is a "dontzap" program you can run once to re-enable that feature. I
suggest a similar solution to this problem, as it is a rather similar
solution. Find their precedents for this action, and you will find logic
that should be somewhat applicable to this case.

On Fri, Dec 18, 2009 at 12:16 PM, Arvind S Raj <email address hidden>wrote:

> Well then what could be a possible solution? Not many Ubuntu users will
> appreciate the fact that terminal will give a feedback such as stars (as
> many stated here) and not many new users will remember unless reminded
> about this just like what Blattlaus said in comment #16. Perhaps a timed
> reminder in interval of a few days or something?
>
> --
> Entering password in Terminal gives no visual feedback
> https://bugs.launchpad.net/bugs/194472
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: Confirmed
> Status in sudo: Fix Released
> Status in “sudo” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: sudo
>
> Until a user entered his first "sudo" command he sees these lines every
> time he opens a terminal
>
> --
> To run a command as administrator (user "root"), use "sudo <command>".
> See "man sudo_root" for details.
>
> foo@bar:~$
> ---
>
> After the first sudo command ~/.sudo_as_admin_successful is created and
> terminal starts with a simple prompt.
>
> Now my point: I'm reading a lot of forum postings and every other day
> someone with little experience in linux and shell commands asks the question
> "I'm trying to execute sudo $command, but when i try to enter my password
> nothing happens, i can't see what i'm typing and i also don't see asteriks
> like ***, so is my keyboard dead?".
>
> So please could you add a little sentence, that you can't see asteriks or
> your password while entering your sudo password. This would reduce the
> confusion a little bit (if people would read that note ;)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/194472/+subscribe
>

--
Sincerely,
   Josh

I have just created a branch which adds to pwfeedback option by default to the /etc/sudoers file, this means visual feedback is given when a password is entered.

Now all that needs to be done is the new version of sudo synced across

For whoever can update the sudo package, it needs to be the newest version from cvs

Thanks Andrew , could you also mention which changes/patches from upstream need to be cherry-picked to implement this?

Sure I shall have a go...

There was a bit of confusion but all that needs to happen now is sudo needs to be synced from debian, and the debdiff applied

Why don't admins with this problem just add a message to the MOTD.
I don't think it's good idea to change sudo at all.
Kind of makes Ubuntu users look like morons.

Why is this a papercut? Dozens of papercuts have already been rejected because papercuts don't apply to the command-line. Ubuntu shouldn't trying to make the CLI user friendly - it should be fixing problems that exist at the GUI level. Please don't apply this patch, it is not solving a real problem.

I'd like to have some form of visual recognition that I've typed in the correct number of letters. I've on occasion missed a letter even though I thought I pressed it.

Perhaps this could be a setting that could be set? For example the default is show asterisks, but the admin could set it to display no output.

Depending on the feedback, a shoulder-surfer could figure out how long the password is, which could be useful in an attack. Also, if visual feedback is enabled, it will diverge from other standard login procedures such as 'login' and 'ssh'. This should not be the default, but could be configurable for those who want it.

Thanks Andrew for you branch. It looks good to me. However, sudo 1.7.1 is required which should be merged from Debian testing.

The core issue here is whether visual feedback should be given when a password is entered. Depending on the outcome of this decision the proposed branch should be merged or not.

I'm unsubscribing the ubuntu-main-sponsor team until a definite decision has been reached. Please resubscribe the team if a decision to enable visual feedback by default has been taken, sudo 1.7.1 is available in Ubuntu, and the bzr branch has been updated to the match the package in Ubuntu.

@David Siegel:

Can we have a decision :-)

If we expect standard Ubuntu users to use sudo, then my previous comment applies: either sudo should show feedback for each password character typed, or gksudo and PolicyKit should not.

But I think our long-term aim should be that sudo is used only by server administrators and software developers. Any situation where standard Ubuntu users feel the need to use sudo, *that* is a bug that should be fixed. <https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-no-sudo> As long as we expect to be able to give users instructions that involve the terminal, they will be at risk from people giving them malicious instructions, because a terminal can't possibly convey danger as effectively as a graphical interface can. We need to get to a point where anyone posting terminal instructions, for people other than server administrators and software developers to use, is shouted down -- just as they would be in Windows or Mac OS X.

So if servers have a higher security standard, such that showing feedback when typing your password would annoy or freak out administrators, then we shouldn't make any change to sudo. I don't know whether that's true, because I haven't done any user research on server administrators.

Closing papercut task.
As this change needs to be decided by the server team.

Before we get comments for or against the change, Desktop goal, as mpt mentions, is to shout at any one who recommends average users to use terminal.
So let's start shouting and fix the main bug. ;-)

mpt,

In my last comment, it is the server (or remote) administrator that I was most thinking about, as he/she is very used to the CLI and (as mentioned in my previous comment) are used to sudo and other programs not giving the feedback. I haven't researched it either, but it seems clear to me that server admins would indeed freak out. FWIW (and that very well might not be much), the desktop (ie GUI) requirement for feedback and the server (ie CLI) requirement for feedback are quite different (though with my security hat on, I'd prefer desktop to not have the feedback but realize that is problematic).

Adding server-papercuts task .
The server team mentioned they would have a look at this closer when they had a dedicated server-papercuts project.

The bug already has a patch and from what Andrew mentions it shows stars only during entry and it disappears once the users hits "return" ...

I reiterate my belief that this issue is too contentious to be a genuine papercut.

As a server admin for a number of Linux/UNIX hosts, I would advise that sudo is left as-is and the notification at login is updated as suggested by the original submitter of the bug. Showing the length of a password at the sudo prompt makes it significantly easier to perform a brute force attack on the password as the hacker now knows to brute force with the correct length without any trial and error required.

This is highly questionable, as most Ubuntu Server users would not want such a change. Definitely not the "everyone agrees" type of Papercut. Invalidated in 20100210 meeting.

So what about my initial proposal. Today - like every other day - someone showed up at ubuntuusers.de and asked...

Original posting in german... http://forum.ubuntuusers.de/topic/passworteingabe-im-terminal-nicht-moeglich-1/

> Immer wenn ich im Terminal dazu aufgefordert werde mein Passwort einzugeben, ist dies nicht möglich. Ich kann im Terminal ganz normal mit der Tastatur tippen, bis es dann zur Passworteingabe kommt, dann weigert sich die Tastatur irgendetwas zu machen. Nur die Enter-Taster funktioniert. Was mache ich falsch? Wie kann man das beheben?

Rough translation into english.

> Whenever the system asks me to enter a password, it's not possible. I can type inside a terminal until i have to enter my passwort, the keyboard jams and except "Enter" nothing works. What am I doing worng.

I don't ask to patch sudo, my only hope is ONE sentence which explains that you won't get visual feedback while typing your password. Sure, not everybody will read this line, but some people will.

A Modest Proposal

On what street corner of the internet will one *not* find confusion from
newcomers of the sudo entry method? It is obvious that something is wrong...
and any who say *not* to change even the least part is being stubbornly
traditional... *how* to change? this may be the challenge. I would vote that
at least we need to have an explanatory sentence; but preferably it would
default to *the standard password entry method* of Ubuntu, which just so
happens to be password length indicative. Every once in awhile, it comes
time to take out the trash. Take Out The Trash. The hardcore geeks who want
their old fashioned, esoteric entry method would not be stopped from getting
it out of the landfill. (aka. just make a preference with the default being
the one that matches Ubuntu philosophy and practice, password length
indicative!) This post was not meant to be offensive in any way, merely I am
trying to make a point. Yes, we could NDisWrap every wireless driver like
its 2005, but we've got more effective and intuitive ways to get wireless
connections going. Why, when countless newcomers *will* use the terminal, do
we refrain from doing what is best for the majority of users? There is a
paranoid minority that has voiced security concerns about people seeing the
length of a password... yet they say nothing about gksudo? Let it be known
that this day, February 21, is the day that sudo moved out of the Age of the
Wizards and into the Age of Humans; and let it be done with ubuntu (actual
word) on Ubuntu. (the OS)

This was a bit satirical, but I hope that each of you who read this will
understand what is meant, and will act for the benefit of the community.

On Sun, Feb 21, 2010 at 11:14 AM, Christoph Langner <
<email address hidden>> wrote:

> So what about my initial proposal. Today - like every other day -
> someone showed up at ubuntuusers.de and asked...
>
> Original posting in german... http://forum.ubuntuusers.de/topic
> /passworteingabe-im-terminal-nicht-moeglich-1/<http://forum.ubuntuusers.de/topic%0A/passworteingabe-im-terminal-nicht-moeglich-1/>
>
> > Immer wenn ich im Terminal dazu aufgefordert werde mein Passwort
> einzugeben, ist dies nicht möglich. Ich kann im Terminal ganz normal mit
> der Tastatur tippen, bis es dann zur Passworteingabe kommt, dann weigert
> sich die Tastatur irgendetwas zu machen. Nur die Enter-Taster
> funktioniert. Was mache ich falsch? Wie kann man das beheben?
>
> Rough translation into english.
>
> > Whenever the system asks me to enter a password, it's not possible. I
> can type inside a terminal until i have to enter my passwort, the
> keyboard jams and except "Enter" nothing works. What am I doing worng.
>
> I don't ask to patch sudo, my only hope is ONE sentence which explains
> that you won't get visual feedback while typing your password. Sure, not
> everybody will read this line, but some people will.
>
> --
> Entering password in Terminal gives no visual feedback
> https://bugs.launchpad.net/bugs/194472
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: Invalid
> Status in Ubuntu Server papercuts: Invalid
> Status in s...

Oh, and i do like how everyone kindly ignored my comment [#35] that seriously owned EVERY 'its a standard!' argument on the page... no offense, but seriously guys. The solution is ready, why won't we implement it? The only way new users won't be found in the terminal pretty soon after getting into Ubuntu is to remove it. So, take that approach if you want, otherwise be realistic and maybe we can save some bandwidth on the Ubuntu Forums. I really think this should make it into the LTS... but I guess there may be too much rust for the wheel of change to start turning on this issue. I'm disappointed in this matter, but if we can't have terminal feedback, I want my Ctrl-Alt-Delete back by default, you know, for the sake of tradition.

If it is really security-relevant for servers (which i doubt), why not enable it just on the desktop?

Can anyone explain why this would be a security issue?
I think, if someone or a tool can read the output of the visual feedback. The person or tool has already other ways of getting the length of the password.

Josh Leverette wrote on 2010-02-22:
"Let it be known that this day, February 21, is the day that sudo moved out of the Age of the Wizards and into the Age of Humans"

Why should sudo be moved to the Age of Humans? It really doesn't belong there. As Matthew Paul Thomas mentioned it isn't time to change sudo, but to change those users who keep on posting difficult commands which a user doesn't undestand. Stop those forum members from saying: "Just enter 'sudo apt-get install app-name' in the Terminal." A user doesn't know what this command does. Just tell him where to click to install this application. Tell the forum administrators to edit or remove these kind of Terminal posts and replace them with proper GUI posts. Send a warning to people who keep on posting Terminal commands. That's what needs to happen.

A user doesn't type a sudo command of oneself. They type those commands, because they were told to do so by members on the forum. Those people need to change. Just let them explain how to do some task using the GUI and only tell a user to use a Terminal command if the user asks for a command.

@Tralalalala, then we're back in the world of Microsoft Windows, where everything has to be done with a GUI and nobody knows the technique behind the shell. Forums, Blogs, Wikis... all these types of media are text based. It's much more easy, much faster, more precise and less error-prone to use commands in text based media instead of "Go here, open window foo, look for checkbox bar, then click here and there"...

But please, it looks like it's not possible - or better - it's not wanted to change the way sudo behaves. That's fine with me. But please PLEASE add one line to the initial message which explains the behaviour.

Actually, this is easy to configure now in /etc/sudoers, as of Ubuntu Lucid.

Edit that file and changing one line:

-Defaults env_reset
+Defaults env_reset,pwfeedback

Save that file to disk and now try:

$ sudo -k /bin/true
[sudo] password for kirkland: ***************

Note that as soon as I hit "enter" all of the asterisks are deleted, masking my password once again.

Now the question ... Should we change this default value for Lucid?

Giving my two cents to my previous question... Yes, I think we should change the default /etc/sudoers configuration for Lucid to enable pwfeedback.

I believe we should because:
 a) gksudo, pinentry, kdesu, etc. all have password feedback, and it's one-for-one with the characters typed
 b) the asterisks go away as soon as you hit enter
 c) it is a user friendliness thing, that would make Ubuntu just a little bit nicer for first time users
 d) it's easy to disable if you don't like it

I suggest that we turn this on for new installations of Lucid, but do nothing on upgrades, and instead document how easy it is to turn it on after the fact for an upgrade. Presumably if someone has upgraded to Lucid, they have been using Ubuntu long enough to realize that sudo doesn't provide feedback while typing.

I'd like to get one of the Security team's input on this, and assuming they do not have objections, I'll JFDI.

Per discussion in #ubuntu-hardened, the Ubuntu Security guys are opposed to the change I proposed above.

Thus, this bug is closed, and should be handled in documentation.

I have added a section to the sudoer's documentation:
 * https://help.ubuntu.com/community/Sudoers#Enabling%20Visual%20Feedback%20when%20Typing%20Passwords

Those who want to enable visual feedback, can do so in the configuration file. Sorry.

Seriously? #ubuntu-hardened isn't a supreme court.... this can be discussed
so that by reasoning with them they would see that this isn't really a
security issue. However, I do propose one final alternative. The first time
you run sudo you should get to type a number, 1 or 2, and choose whether you
want to enable or disable visual feedback. And furthermore, there definitely
needs to be a one liner to tell people what's up if that option isn't
viable.

On Tue, Feb 23, 2010 at 6:25 PM, Dustin Kirkland
<email address hidden>wrote:

> Per discussion in #ubuntu-hardened, the Ubuntu Security guys are opposed
> to the change I proposed above.
>
> Thus, this bug is closed, and should be handled in documentation.
>
> I have added a section to the sudoer's documentation:
> *
> https://help.ubuntu.com/community/Sudoers#Enabling%20Visual%20Feedback%20when%20Typing%20Passwords
>
> Those who want to enable visual feedback, can do so in the configuration
> file. Sorry.
>
> --
> Entering password in Terminal gives no visual feedback
> https://bugs.launchpad.net/bugs/194472
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in One Hundred Paper Cuts: Confirmed
> Status in Ubuntu Server papercuts: Invalid
> Status in sudo: Fix Released
> Status in “sudo” package in Ubuntu: Won't Fix
>
> Bug description:
> Binary package hint: sudo
>
> Until a user entered his first "sudo" command he sees these lines every
> time he opens a terminal
>
> --
> To run a command as administrator (user "root"), use "sudo <command>".
> See "man sudo_root" for details.
>
> foo@bar:~$
> ---
>
> After the first sudo command ~/.sudo_as_admin_successful is created and
> terminal starts with a simple prompt.
>
> Now my point: I'm reading a lot of forum postings and every other day
> someone with little experience in linux and shell commands asks the question
> "I'm trying to execute sudo $command, but when i try to enter my password
> nothing happens, i can't see what i'm typing and i also don't see asteriks
> like ***, so is my keyboard dead?".
>
> So please could you add a little sentence, that you can't see asteriks or
> your password while entering your sudo password. This would reduce the
> confusion a little bit (if people would read that note ;)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/194472/+subscribe
>

--
Sincerely,
   Josh

On Tue, 2010-02-23 at 23:25 +0000, Dustin Kirkland wrote:
> Per discussion in #ubuntu-hardened, the Ubuntu Security guys are opposed
> to the change I proposed above.
>
> Thus, this bug is closed, and should be handled in documentation.
>
> I have added a section to the sudoer's documentation:
> * https://help.ubuntu.com/community/Sudoers#Enabling%20Visual%20Feedback%20when%20Typing%20Passwords
>
> Those who want to enable visual feedback, can do so in the configuration
> file. Sorry.
>

Dustin ,
Does that really help? The bug here was because desktop users were
really confused that the terminal/sudo did not give a feedback when
every other gksu/policykit/gdm show the feedback.

If a user is aware enough to check the wiki and change that setting,
then editing the setting is not even essential. And it does not solve
any problem or this bug.

Users commenting here know that sudo gives no feedback and if needed
might enable the setting, but
- what about the users who _dont_ know why this is happening?
- why/how would they come upon the wiki to check and enable the
feedback? They would not even be aware that they need to set this up.

On the contrary , IMO , this can be enabled by default[atleast for
desktops] and the wiki can be for _disabling_ it , as that would be the
more common scenario for a user checking the wikis.

@ Security team:
If the temporary feedback is such a huge security issue ,
policykit/gksu/gdm[more commonly used than sudo] always display
feedback.
Why has that not been changed , is the Ubuntu OS' security severely
compromised now?
Are we planning to stop them from show feedback to improve security?
If no _active_ steps are being taken to prevent the feedback in those
places , why are we preventing the feedback in sudo?

Users new to Ubuntu will continue to use sudo and the terminal in Lucid. One reason for that is forums and another is our own documentation. Here is an example - and remember that without running this command no user will be able to watch their DVDs:

sudo /usr/share/doc/libdvdread4/install-css.sh

I notice several suggestions:
1. Add text explaining that sudo will not give feedback,
2. Make Lucid use pwfeedback,
3. Enable pwfeedback only in the desktop edition,
3. Use an animation that doesn't reveal the password length but does provide feedback

The only alternative I see that would solve the problem is for all forums and documentation to replace sudo with gksudo.

gdm doesn't always provide feedback; we do that by default. It can too hide feedback, which i would prefer. FWIW, i would hate to see this changed in sudo. I'd rather see all other tools not providing feedback :) But, that's just me...

I see the security point issue behind this but I also see the issue.

One use case that I see for it is when I am typing in my sudo password I don't know if I put in too many letters. I often have to CTRL C to escape out and try again.

But I do agree this should not be on by default on server. I also think that this should only be enabled if it is easily changeable via vsudo.

My 2 cents:

For server, there are lots of other places where password behaves the same (including login) so for consistency I wouldn't change sudo behavior.

For desktop, in most places, privileged actions trigger a GUI pop-up in which you enter your password (with the "usual" password feedback). If I use run ssh client on a server, I have to enter my passphrase at the terminal prompt. If I do the same on a desktop, I get a neat pop-up in which I can type my passphrase. I think sudo should ideally behave the same...

I didn't look into feasibility at all here, and I assume if it was that easy it would already have been done. I just don't think we should have a different "sudo" behavior *in terminal* based on an abstract detection of desktop/server. I think sudo could on X-enabled systems ask for its password in a different way.

@jdstrand: is this a security issue that is so large ,in the desktop edition, to make sudo behave differently ?
If so , is there anything being done _actively_ to prevent feedback in other places in the desktop ?
If not, why enforce this in sudo for the desktop edition?

This simple bug is not be fixed because , everyone has passed the buck and does not want to take responsibility

Design team > server team
Desktop team > server team
And now the server team says its ok for the desktop edition to display feedback [similar to the rest of the desktop, but not for server edition] !

This is something that has confused a bunch of people who I have gotten to try out Ubuntu.

Any chance this will get fixed in Maverick?

Quite regularly (anywhere between a couple of days and every few weeks), we get a thread like this on the Ubuntu Forums:
http://ubuntuforums.org/showthread.php?t=1567907

Easier to count key clicks than asterisks if you're standing behind someone. Lack of visual feedback offers no security advantage--just comfort to *nix users who are used to it.

My main objection is that if this is enabled only for Desktop, suddenly the behavior of sudo changes based on what ISO a person installed from. This seems confusing.

I should clarify a bit more. This would be a change visible at the command line. The bulk of Desktop users will be using gksudo, and not the command line. For those that use the command line, this would suddenly become a difference between server and desktop installs. It may cause package merge confusion, etc. Since sudo from the command line is traditionally a server-only thing to do, it should be consistent with existing expectations and not change.

I do not see the value of this change due to the larger audience that would find the change disruptive.

The security team has consensus for the security impact which I will detail in this comment. As developers, we have other concerns which will hopefully also be considered, and we will comment separately.

There are security implications to visual feedback of passwords. The security team feels this approach is wrong for all Ubuntu applications. We recognize this stance is contentious and may be impractical when considering some upstream applications.

For sudo and the current state of applications as included in Ubuntu, we feel enabling password feedback in sudo:
1. has a security impact on the server where no other application gives password feedback. We strongly discourage changing the behavior on server installs
2. has no significant security impact on desktop installs when the screensaver, policykit, gksu, and gdm (kdm?) all give feedback. As mentioned in comment #60, the asterisks are removed after pressing Enter, but it is recommended that this happens for all of gnome-terminal, konsole, xfce4-terminal and xterm (and any others people would like to test). We do not want visual feedback saved in scrollback or history.

If this must be implemented at all:
1. we should not have separate sudo packages with different /etc/sudoers files for different installs. This is too difficult to audit.
2. /etc/sudoers should not be touched (on upgrades or otherwise) since this could lead to severe security (and other) consequences
3. the sudo configuration should only be adjusted for new desktop installs

One way to achieve 1-3 is to closely look at the /etc/sudoers.d mechanism, since it is designed for this sort of thing.

As a developer, I agree with Kees and feel that having different sudo defaults for different Ubuntu installations is odd and confusing for people new to Ubuntu. New Ubuntu desktop users should not be directed to open a terminal and type sudo commands at all, and should be directed to use the existing graphical tools to administer their system and where they are not enough, use gksudo. However, people used to Ubuntu desktop and using sudo on it who try out Ubuntu server are almost guaranteed to be confused. As such, IMO this should be fixed in documentation surrounding the use of sudo on the desktop (ie, use the gui tools or gksudo), and not in the sudo configuration.

"New Ubuntu desktop users should not be directed to open a terminal and type sudo commands at all"

How are you going to enforce that exactly? There are hundreds or thousands of online tutorials for Ubuntu desktop installations that involve copying and pasting commands into the terminal. And that is also the method used at least half the time on the Ubuntu Forums to give help to new users.

You can argue all you want that in theory desktop users should be using graphical tools for everything, but that isn't the reality.

I didn't say it was a reality. I said it is what should happen and that if we pursue having different sudo configurations for desktops and servers we may as well open another usability bug for people being confused by this new situation. We can fix our wiki and help documentation but if people are going outside of official documentation then they really need to be familiar with the command they are running (well, you always do ;). Some degree of confusion there could lead to actually reading documentation.

The security team's perspective has been addressed sufficiently by Jamie, I think.

One of the difficulties here is that there is no distinct line between what is a "server" and what is a "desktop"; tasks from each are often commingled on the same machine. Anyone who has spent any time in the #ubuntu-server IRC channel has seen how common it is for people. Commonly, web application/service developers will develop and test using a web server on their desktop and then deploy to a production server environment. As such, they are likely to get confusing behavior, and despite what we might desire, these people can often be quite new and inexperienced in using Linux environments; precisely the people we're trying to help. Anyone who has spent any time in the #ubuntu-server IRC channel has seen how common it is for people with less experience asking whether it's okay to install desktop software in a server environment.

I personally like Thierry's proposed approach of using a pop-up dialog when DISPLAY is set, though there may be some issue I'm overlooking. One tricky bit is that for where ssh X forwarding is used, the server is unlikely to have gksudo or other X based dialog utility installed.

Here is where this bug stands:
The desktop team has mentioned that they will *not* veto a change regarding this.
There are members willing to upload a change to fix this bug, but this bug was blocked due to Security team's earlier vague comment. [which turns out to be a concern about server installs]

Security team has now discussed and mentioned their concerns and has given us how this needs to be fixed for new desktop installs.

Now, someone needs to work on a fix as mentioned by security team in comment #74 .

Once this is fixed ,the previous addition in the help documentation needs to be changed to mention how to not show passwords for users who are concerned. [a reminder the password stars will only be shown until the user hits enter , once the user hits enter it will be erased. ]

Since there is such a fine line between server and desktop use, to avoid confusion there should be a consistent behavior--either the password has visual feedback or it doesn't.

So if this is really a security issue (showing feedback), then there should be no feedback ever. No dots or asterisks for the GUI environment. No asterisks for the CLI.

But if it isn't a security issue, then it's really just a matter of "what old *nix users are used to" as opposed to what makes the most sense, in which case dots or asterisks should be used in both the GUI and the CLI.

This is overstated:
"Security team has now discussed and mentioned their concerns and has given us how this needs to be fixed for new desktop installs."

We have given our concerns from a security point of view as a team and have given our views individually as developers. This does not 'need' to be fixed on the desktop, but if people want to pursue different configurations for desktop and server, it 'could' be fixed by following a few guidelines.

jdstrand, err.. yep! of course.. ;-)

I'm pleased that the discussion is open again.
May I ask the Server Security team to clarify what it means "1. has a security impact on the server where no other application gives password feedback."
Where does the security issue lie? I can't imagine a case, where anyone or any program could see the asterisks but not be able to register at least the keyboard-strokes.
And if it is, wouldn't it be enough to be able to disable it for the ones who care about such fine grained security. Ubuntu is anyway not the safest server environment with much features enabled by default.

Phillip:

This is not the 'Server Security' team, but the Ubuntu Security team. As mentioned earlier in this thread, no other applications in the default server install provide password feedback (eg, console login and ssh). Therefore, a shoulder surfer cannot obtain the password length via those applications. If we add password feedback to sudo on the server, then sudo provides an avenue for enumerating the password length where one did not exist before. This is undesirable.

"Ubuntu is anyway not the safest server environment with much features enabled by default."
Please file a separate bug with specifics on what you consider to not be safe in a default server install.

Can we put the "shoulder surfer" myth to bed once and for all?

First of all, if your password is of any considerable length, there's no way the human eye can tell the difference between 11 asterisks and 13 asterisks in the blink of an eye. And if your password is 12 or 13 characters long, it'll take nearly forever to crack anyway if length alone is the only thing you know.

Secondly, anyone standing behind you can count keyboard clicks better than counting asterisks and have the bonus of seeing at least some of the keys you're pressing or at the very least which sides of the keyboard you favor at different parts of your password.

If someone is standing over your shoulder, not getting visual feedback doesn't mean staying secure. Shoo that person away, seriously.

This bug is about coherence.

The advocates for the change say that desktop applications give password feedback, so sudo should do as well. I advocate against the change for the same reason: server applications don't give password feedback, so sudo should not as well.

The correct way to fix this is *not* by screwing off one population to help the other. The correct way to fix this is to have different prompts for desktop and server users, based on availability of a DISPLAY. This is already done for login, SSH passphrases. In Maverick I noticed that my gpg-password-protected files now also trigger a modal visual password prompt window. sudo should do the same. It's certainly a more complex ride, but it's the right way.

"2. has no significant security impact on desktop installs when the screensaver, policykit, gksu, and gdm (kdm?) all give feedback. As mentioned in comment #60, the asterisks are removed after pressing Enter, but it is recommended that this happens for all of gnome-terminal, konsole, xfce4-terminal and xterm (and any others people would like to test). We do not want visual feedback saved in scrollback or history."

Jamie, what about if sudo showed the asterisks while you were typing, but then deleted them the moment you pressed Enter? Then they wouldn't be in scrollback or history. Would that be acceptable on a server?

I'm very skeptical that there is a real problem here to be solved, or a fix that would be any better than any proposed fix. I also don't see this debate ever coming to a conclusion. I understand that a few users are initially stumped by this, but in my opinion, we should be focusing our polishing efforts elsewhere, and leave the CLI optimized for people who need or prefer it.

I understand that there are very strong belives here. If devs think, that the asterisks should not be shown, then this is fine with me. But why not just edit the text which is displayed when someone opens a terminal? Please read what I wrote in the first posting of this issue...

<--- cut --->
Until a user entered his first "sudo" command he sees these lines every time he opens a terminal

--
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

foo@bar:~$
---

[...]

***So please could you add a little sentence, that you can't see asteriks or your password while entering your sudo password. This would reduce the confusion a little bit (if people would read that note ;)***
<--- cut --->

I think that this could be a good compromise here?

mpt: Sorry I wasn't clear; 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.

"we should be focusing our polishing efforts elsewhere, and leave the CLI optimized for people who need or prefer it."

So is there a papercut for taking the terminal out of the desktop .iso by default and then forcing desktop users to install it via Synaptic if they want it? Or taking all terminal commands out of the community site documentation? New users aren't pasting in terminal commands they've memorized. They are getting these commands from tutorials targeted at new users.

If you are going to take the "Well, new users shouldn't be using the terminal anyway" approach, you have to fully back that approach and not encourage them to use the terminal.

@Rick Spencer,
Last time we discussed this bug :
 - The desktop team mentioned that sudo-less desktop will *never* be achieved. And it is highly unlikely that Ubuntu desktop will /ever/ ship without sudo.
 - The team dont want to take responsibility for the change [fearing backlash from the cli-loving community]
 - That they would *not* object to this change. And would not actively work on this bug.
 - *But* are welcome if someone wants to work on it.
 - You did mention trying the change [as a trial phase] early in maverick alpha, so that the change can be assessed by the wider community and then decided before the final release.

What has changed since then? Why trying to close this issue now?
What is the issue if other teams work on it and take responsibility, why is desktop team now deciding that efforts from other teams too are best put elsewhere?

This is not a random controversial idea we just came up with and trying to push on Ubuntu. There is a genuine concern here and we are trying to fix it.

This bug can be fixed either by: [easiest to toughest]
1 - Removing sudo from desktop » desktop team already rejected this utopia «
or
2 - If someone works on a fix, trial phase this change during early Natty [or which ever release] and then decide before final.
or
3 - Announce and make sure that all ubuntu docs, ubuntu help , support in lp.answers , support in forums, blogs everywhere on the planet need to be fixed so that sudo is not referenced in their tutorials.
ex: documentation used for SRU > https://wiki.ubuntu.com/Testing/EnableProposed , [SRU wiki is more likely to be referred by a new user, than other high level docs, let alone problems for hardware issues] all the documentation everywhere need to be checked and changed.
4 - or what ttx mentions in comment#86

Alternatively, How do you suggest the likely fix for this problem be?
We are open to other suggestions too. There is a problem and looking the other way just because we've grown to expect a certain behavior from an app is not a right fix here.

Jamie, you were perfectly clear. I was asking your opinion on a new design possibility that the security team had not considered. What is the team's position on the design I proposed? Thanks.

If even that would be unacceptable, then this bug should be marked Won't Fix. If it would be acceptable, then this bug should be fixed. "Opinion" is an inappropriate status for Ubuntu bug reports.

Sorry, I missed comments 60 and 62. My mistake. :-) In that case, this is Won't Fix.

Heh, shouldnt have told mpt to look at comment #60 ;p