Lack of visual feedback on password entry

Bug #52914 reported by aysiu on 2006-07-13
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
shadow (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: gnome-terminal

In graphical applications, asterisks or black circles indicate visually as you're typing that your password is being typed. The terminal gives you no such indication, and this is sometimes confusing to new users.

Asterisks in the terminal or the disappearance of asterisks from the graphical password prompts would be more consistent and less confusing.

By the way, a similar problem exists in Konsole, too.

Andrew Medico (a-medico) wrote :

The terminal emulator has no control over this. Whether or not asterisks are shown during password entry is up to each application (or the library it uses).

Is this a bash issue?

Dean Sas (dsas) wrote :

No it happens with all shells for every Unix varient I've ever used. I don't imagine people wanting to change this.

Colin Watson (cjwatson) wrote :

I don't particularly want to change this in shadow; I would get complaints citing security (i.e. you can look over somebody's shoulder and see the number of characters in their password).

I also doubt the desktop folks will want to change their situation, citing usability as you do.

I realise it's inconsistent, but, given the tension here, I think if there is an inconsistency then it's probably in the right place. It's configurable in at least /etc/gdm/gdm.conf:

# Do not show any visible feedback in the password field. This is standard for
# instance in console, xdm and ssh.
#UseInvisibleInEntry=false

... and it's configurable in /etc/login.defs:

# When prompting for password without echo, getpass() can optionally
# display a random number (in the range 1 to GETPASS_ASTERISKS) of '*'
# characters for each character typed. This feature is designed to
# confuse people looking over your shoulder when you enter a password :-).
# Also, the new getpass() accepts both Backspace (8) and Delete (127)
# keys to delete previous character (to cope with different terminal
# types), Control-U to delete all characters, and beeps when there are
# no more characters to delete, or too many characters entered.
#
# Setting GETPASS_ASTERISKS to 1 results in more traditional behaviour -
# exactly one '*' displayed for each character typed.
#
# Setting GETPASS_ASTERISKS to 0 disables the '*' characters (Backspace,
# Delete, Control-U and beep continue to work as described above).
#
# Setting GETPASS_ASTERISKS to -1 reverts to the traditional getpass()
# without any new features. This is the default.
#
#GETPASS_ASTERISKS 1

Changed in shadow:
importance: Untriaged → Wishlist
status: Unconfirmed → Rejected
pererik87 (pererik87) wrote :

what if it says
Password: Typing
or only one star
while typing

and
Password: Accepted
when done

I understand if you don't want to fix this bug for the reasons you stated (you would get complaints), but I have a problem with this line:

"I would get complaints citing security (i.e. you can look over somebody's shoulder and see the number of characters in their password)."

Anyone standing next to you who wants to know the number of characters in your password can just listen for the number of clicks on your keyboard, no matter how fast you type. And if you have a really long password (13 characters, for example), can someone really tell the difference at a glance between 13 asterisks side-by-side and 11 asterisks side-by-side? How easy would it be to crack a password knowing that it has 13 characters in it?

By the way, you can also, in addition to listening to the number of clicks on the keyboard, actually look at the keyboard itself to see what keys are being hit or which side of the keyboard is being typed on during different parts of the password. That won't give you the whole password, obviously, if the person entering it types quickly, but knowing one or two characters in addition to how many key clacks is far more useful to compromising security than just seeing a bunch of asterisks.

Again, I understand why you won't fix it (people will get all upset, because this is the way it's always been), but can we please stop pretending it's about security.

It'd also be great if this was changed from "invalid" to "won't fix." It's not an invalid bug. It's a usability bug that exists.

Colin Watson (cjwatson) wrote :

You may note from the bug history that it was originally "Rejected", before that status was split into two in Launchpad.

Changed in shadow (Ubuntu):
status: Invalid → Won't Fix
Ishan A B Ambanwela (ishanaba) wrote :

I have been with Ubuntu since the begining and I have no problem with this at all. My observation is non technical uses are really confused with this setting.
For a server os this might not be a poblem but as a Desktop OS variant this kind of usability issues can be eliminated easily and it might save some time of both users and help desk.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers