Do you think this is a security risk and if not is it a bad UI decision?

Stephen Gallagher sgallagh at
Mon May 6 13:36:54 UTC 2013

Hash: SHA1

On 05/06/2013 09:27 AM, Josh Bressers wrote:
>> "Will and Mairin had some good links talking about the merits of
>> doing this and how hiding passwords doesn't even do all that much
>> to help (a determined person can always just watch your
>> keyboard)."

Sure, a person can watch your keyboard, but it's usually more obvious
than someone glancing at your screen. Your body tends to be
unconsciously huddled over the keyboard when typing a password,
obscuring view.(Not to mention that unless you have a VERY
high-precision camera pointed the right way (or you type about 5 wpm),
most of the time a human won't be able to follow your keystrokes.

> This argument isn't very solid. I mean someone can just break your 
> window to get in your house, so locking the door is waste of time, 
> right? The bigger issue here is we should always have the mantra 
> "secure by default". This is not secure by default.

I agree strongly here. I have no problems with *permitting* the user
to view the password unmasked, but doing so by default is just wrong.

>> "Why not use a checkbox?  Well, why use a widget if we don't have
>> to? Using a checkbox means now we have to work in another widget
>> to the design, introducing potential padding and layout problems.
>> It's another string that needs to be translated.  It's another
>> thing that needs a mnemonic widget.  By doing the focus trick, we
>> completely get rid of the keyboard layout problem because you can
>> see what you're typing as you're typing it.  It may also even
>> allow us to get rid of the confirmation entries for the same
>> reason."
> A checkbox is probably the right way to handle this. While yes
> it's slightly more work, it does two very important things. It puts
> the user in control, and it is secure by default.

Agreed. Please add the widget. "It's more work" is not a valid answer.
Yes I realize this means layout and translation changes. It also means
that the installer is less prone to shoulder-surfing information
leaks. The gains far outweigh the (perceived) costs.

> Security is hard, and many security decisions can often have 
> unintended impacts. I suspect in this instance, a new Fedora user
> (and even some old ones) will see this behavior and think one of
> two things. 1) It's a bug. 2) These people know NOTHING about
> security! Neither is an ideal outcome.

Yes, if nothing else, most users have been trained for many years that
protecting their passwords is important. To have us suddenly
displaying it for all to see (installer demos at conferences?) makes
us look like we are intentionally ignoring "conventional wisdom". (I'm
not going to make any statements about the research studies here. At
the moment I'm only talking about perception). Users *will* report
this as a bug, and I would not be surprised if some people refuse to
install Fedora because of it. I certainly wouldn't use the installer
in a public place (even in the office, where someone could walk by
wearing a pair of Google Glasses).

> Regardless of all the studies that say masking passwords doesn't
> help, we can't make this change quickly. We need to slowly ease
> people into such behavior. For now, the best solution is probably a
> checkbox, in a few releases we can revisit what the current
> accepted practice is. The current accepted practice is to mask the
> password, sometimes with a checkbox to unmask (but never unmask by
> default).
> I think a discussion about the merits of password masking could be 
> had, but I'd rather not start down that path. Perhaps the better 
> question is what problem are we trying to solve. Has anyone ever 
> complained about Anaconda masking passwords?

At the risk of sounding glib, when people have complaints about
Anaconda, it's usually about more important things. Let's not try to
solve a non-problem with a dubious solution, yes?

Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the devel mailing list