Description of problem:
On the root password page the password in the confirmation
field is visible as plaintext.

Version-Release number of selected component (if applicable):
F19 TC2
anaconda-19.23-1.fc19 (I think)

Steps to Reproduce:
1. go to root password spoke during installation
2. input root password and confirm input
  
Actual results:
2. confirmation field is in plaintext

Expected results:
2. confirmation field text to be concealed like first field.

I see this when creating either root or user password. The password is visible while inside the box, turns to asterisks if you go outside the box, and becomes visible again if you go back into the box. It happens on GUI install from either the 32- or 64-bit DVD. I haven't checked the netinsts.

Right - I dunno if this is intended to be a feature.

Anyway I think it would much better to have a checkbox
to enable this ("[ ] Show password") - with the default
being not to show the password text explicitly.

I see this also when I want to unlock my LUKS device, using manual partitioning. 
using Beta-TC2 x86_64 netinstall image.

For user creation, the password is shown, too. I like the proposal from #c2 very much, as it don't breaks with earlier behaviour, but still enables to show the typed password.

This is working exactly as it is intended.  The passwords are only visible while they are focused.  As soon as you unfocus a field, the password is hidden.  This is a pattern that is becoming more and more widely used, and it makes sense.  Hiding the password as you type doesn't actually do anything for security, as anyone watching your monitor could just watch your keyboard instead.  There's quite a few papers about this right now.

Showing the password as it is typed solves all the keyboard layout related problems, and in a way that does not require yet another widget which needs layout, translation, and all that kind of stuff.

Your explanation sounds mostly reasonable, but I'm still concerned about the fact that the focus isn't always intentional, and the user might not immediately notice it. For example, if you use a weak password, and click Done, the focus goes back to one of the password windows and you have to click on Done again for it to take. Could the focus stay on Done, so that doesn't happen?

Filed https://bugzilla.redhat.com/show_bug.cgi?id=959463 for focus going into password box unexpectedly.

*** Bug 959541 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
>This is a pattern that is becoming more and more widely used.

Where?

What's being more widely used is an icon you click on to show the password next to the field.

>Hiding the password as you type doesn't actually do
> anything for security, as anyone watching your monitor could just watch your
> keyboard instead.  

Not if you're a fast typer.

>There's quite a few papers about this right now.

Link?
 
> Showing the password as it is typed solves all the keyboard layout related
> problems 

How?

>and in a way that does not require yet another widget which needs
> layout, translation, and all that kind of stuff.

> >This is a pattern that is becoming more and more widely used.
> 
> Where?

Searching for "show password on focus" reveals quite a few answers.

> >Hiding the password as you type doesn't actually do
> > anything for security, as anyone watching your monitor could just watch your
> > keyboard instead.  
> 
> Not if you're a fast typer.

Okay, I'll record your typing with my phone and play it back slower later.  Typing speed has nothing to do with anything.

> >There's quite a few papers about this right now.
> 
> Link?

Use google?

> > Showing the password as it is typed solves all the keyboard layout related
> > problems 
> 
> How?
> 
> >and in a way that does not require yet another widget which needs
> > layout, translation, and all that kind of stuff.

Ah, see, you just ignored the second piece of the statement there.

(In reply to comment #10)
> > >This is a pattern that is becoming more and more widely used.
> > 
> > Where?
> 
> Searching for "show password on focus" reveals quite a few answers.
> 
> > >Hiding the password as you type doesn't actually do
> > > anything for security, as anyone watching your monitor could just watch your
> > > keyboard instead.  
> > 
> > Not if you're a fast typer.
> 
> Okay, I'll record your typing with my phone and play it back slower later. 
> Typing speed has nothing to do with anything.
> 
> > >There's quite a few papers about this right now.
> > 
> > Link?
> 
> Use google?
> 
> > > Showing the password as it is typed solves all the keyboard layout related
> > > problems 
> > 
> > How?
> > 
> > >and in a way that does not require yet another widget which needs
> > > layout, translation, and all that kind of stuff.
> 
> Ah, see, you just ignored the second piece of the statement there.

And you ignored "What's being more widely used is an icon you click on to show the password next to the field."

> Okay, I'll record your typing with my phone and play it back slower later. 
> Typing speed has nothing to do with anything.

I'd like to try this experiment with a really long password and see how long it takes you to decrypt it.

Obviously this is one of those "great UI improvement" decisions you have made that you don't plan on fixing. Is that correct?

(In reply to comment #11)
> Obviously this is one of those "great UI improvement" decisions you have
> made that you don't plan on fixing. Is that correct?

If so please close as WONTFIX

(In reply to comment #10)
> Searching for "show password on focus" reveals quite a few answers.

In google, that phrase reveals quite a few user scripts and utilities for doing this. No papers.

In google scholar, it yields no results at all.


> Okay, I'll record your typing with my phone and play it back slower later.

You admit that discovery of the password isn't immediate, by requiring a.) playback, b.) slower, c.) later. The discovery of a plaintext password requires none of these things if the password is even remotely memorable. It's significantly higher chance of successful capture, whether viewed or recorded; compared to a potential capture if viewed or recorded by looking at someone's fingers.


> > Link?
> 
> Use google?

I've spent about 15 minutes on this, which is 10 minutes too long, and I'm not finding anything compelling at all.

A single visible character, delayed transition to obscuring bullet, used on mobile platforms, seems reasonable. Even that effectively guarantees password discovery if the event is recorded, whereas it's merely a potential with no guarantee, if the characters never appear on-screen.

Anyway, I find the argument in favor of this behavior to be specious.

(In reply to comment #13)
> (In reply to comment #10)
> > Searching for "show password on focus" reveals quite a few answers.
> 
> In google, that phrase reveals quite a few user scripts and utilities for
> doing this. No papers.
> 
> In google scholar, it yields no results at all.Onhttps://addons.mozilla.org/En-us/firefox/addon/show-password/ , I found links to several blog posts by famous people, including Bruce Schneier (who is revered by many as a god). That's probably as close to a formal paper as there is.

He recanted.
http://www.out-law.com/page-10152

This whole hoohaa doesn't excite me overmuch, probably because I don't tend to do installs in public, but for what it's worth, from that link cmurf posted:

"Schneier now backs an approach taken by BlackBerry devices and iPhones, which display each character briefly before masking it. "That seems like an excellent compromise," he said."

That's definitely the implementation I've seen in the real world - show one character at a time, either just for a brief moment or until you enter the next one. I can't think of a remotely reputable 'real world' implementation I've seen which only masked when the field was inactive.

*** Bug 959541 has been marked as a duplicate of this bug. ***

Reopening this.  I haven't seen a single paper advocating for this or even a single software do what Anaconda is doing here.  Sometimes, you have an option to show passwords and that would be a nice thing to have and mobile UI might show one character at a time when typing (but only because it is very easy to mistype in a cramped screen) but there is no precedent for showing the entire password when the widget is focused.  Please rethink this.  Thanks

(In reply to comment #10)
> > >This is a pattern that is becoming more and more widely used.
> > 
> > Where?
> 
> Searching for "show password on focus" reveals quite a few answers.
> 
> > >Hiding the password as you type doesn't actually do
> > > anything for security, as anyone watching your monitor could just watch your
> > > keyboard instead.  
> > 
> > Not if you're a fast typer.
> 
> Okay, I'll record your typing with my phone and play it back slower later. 
> Typing speed has nothing to do with anything.
> 
> > >There's quite a few papers about this right now.
> > 
> > Link?
> 
> Use google?
> 
> > > Showing the password as it is typed solves all the keyboard layout related
> > > problems 
> > 
> > How?
> > 
> > >and in a way that does not require yet another widget which needs
> > > layout, translation, and all that kind of stuff.
> 
> Ah, see, you just ignored the second piece of the statement there.

Ah see, now there's a whole thread on devel that disagrees with you and someone else reopened this.

http://lists.fedoraproject.org/pipermail/devel/2013-May/thread.html#182196

(In reply to comment #16)
> This whole hoohaa doesn't excite me overmuch, probably because I don't tend
> to do installs in public, but for what it's worth, from that link cmurf
> posted:
> 
> "Schneier now backs an approach taken by BlackBerry devices and iPhones,
> which display each character briefly before masking it. "That seems like an
> excellent compromise," he said."
> 
> That's definitely the implementation I've seen in the real world - show one
> character at a time, either just for a brief moment or until you enter the
> next one. I can't think of a remotely reputable 'real world' implementation
> I've seen which only masked when the field was inactive.

FWIW, GTK+ can do this with its "gtk-entry-password-hint-timeout" setting.

Apparent justification:
http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/

a phone is a not a desktop. Showing the password while in focus during install of fedora is bad.

The reason for showing the whole password or only the last letter on a phone is because you are using a virtual keyboard with a much higher error rate.

I wonder if anyone has thought about some of the government installations where displaying any kind of password can become a criminal offense? 

At the very least, I would run this by the Redhat security guys before thinking about implementing it.

(In reply to comment #23)
> I wonder if anyone has thought about some of the government installations
> where displaying any kind of password can become a criminal offense? 
> 
> At the very least, I would run this by the Redhat security guys before
> thinking about implementing it.

Of course not. 

Can you please provide any links you might have handy so that this serious isssue is documented in this bug?

Thanks.

Why is this an issue. I find no problem with it.
For example,
In doing the anaconda installation of Fedora or RedHat, you are installing a new linux system.
I just give anaconada the root password 12345. However
On first boot, I log into root and change the password to the ultimate one.

There is a benefit to me vis.

I can give someone the task of installing Fedora, tell him/her to use 12345 as a password, and when it is done, After reboot, I long into root and create a new password, as well as users.

Where is the lost of security.  Do you think that The linux system with the new password, created at boot time, is compromised?

(In reply to comment #25)
> I can give someone the task of installing Fedora, tell him/her to use 12345
> as a password, and when it is done, After reboot, I long into root and
> create a new password, as well as users.

You could do that before, masking the password does not change the ability for you to do that.

> Where is the lost of security.  Do you think that The linux system with the
> new password, created at boot time, is compromised?

Well apparently you think that everyone should change their password right after installing a new system.  Doesn't that negate the point of setting the password to begin with?  If we're going to start mandating this then what's the point of asking for a password at all.

If you're going to ask for a password during the install phase then such a simple standard security practise of masking the password shouldn't even be an issue, it should just be done.

(In reply to comment #25)
> Why is this an issue. I find no problem with it.
> For example,
> In doing the anaconda installation of Fedora or RedHat, you are installing a
> new linux system.
> I just give anaconada the root password 12345. However
> On first boot, I log into root and change the password to the ultimate one.
> 
> There is a benefit to me vis.
> 
> I can give someone the task of installing Fedora, tell him/her to use 12345
> as a password, and when it is done, After reboot, I long into root and
> create a new password, as well as users.
> 
> Where is the lost of security.  Do you think that The linux system with the
> new password, created at boot time, is compromised?

Please say you are joking.

There is simply no sane justification for breaking UX in such a way even if we disregard the (yes, somewhat dubious) security benefits from a previous practice. Standard practice has become masked by default, with an unmasking widget. Alternatively masked by default apart from the last character, with an unmasking widget.

I could agree with having an _explicit_ check "show password" but I would allow
that *ONLY* before I start writing the password - not after.

Here is my addition to comment 25
I install with two full time keyboards.  One has USA English / Canadian French, 
while the second is Latin American (latam)

I do add the keyboard layouts, but there was a problem in the past where. when I entered #@$?() as part of a secure password, that I would have a problem logging into the system immediately after a reboot.

The reason-- # is in a different place on each keyboard layout.
             @ is in a different place on each keyboard layout
etc.
on reboot, did I enter \ (USA English, or # (Canadian French) or
pipe or ? if I had latim layout.

By performing the linux password setup after reboot, the problem for me is and was installed.

By the way, 12345 is in the same location on all three layouts.

For those curious as to what was changed here:

commit da565b769979a031f318dbc727b9888e4f1fb37c
Author: Chris Lumens <clumens@redhat.com>
Date:   Mon May 6 17:18:30 2013 -0400

    Revert "Add signal handlers for controlling password entry visibility." (#95
    
    This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282.

So as things stand, we're back to old-skool masking. I don't know if the devs plan to investigate the alternatives that were proposed.

Chris, thanks for the quick response.

*** Bug 960451 has been marked as a duplicate of this bug. ***

anaconda-19.25-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/anaconda-19.25-1.fc19

Package anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.25-1.fc19 python-blivet-0.13-1.fc19 pykickstart-1.99.30-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7834/python-blivet-0.13-1.fc19,pykickstart-1.99.30-1.fc19,anaconda-19.25-1.fc19
then log in and leave karma (feedback).

anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.