Option to Unhide Entry of Password (AKA "show password" equivalent for current mobile app/webpage idiom)

NEW
Unassigned

Status

()

--
enhancement
9 years ago
20 days ago

People

(Reporter: david, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DUPEME], URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17
Build Identifier: 

Request a preference option such that, if set, passwords are visible instead of being asterisks.  To allay security concerns, this option should require prior entry of the master password before being enabled.  If selected beforehand, the option should expose the entered password while it is being typed.  If selected afterwards, the option should expose the entered password after it was typed.   

Reproducible: Always




As I get older, my fingers do not always do what I want them to do.  When entering a password (especially for a site that blocks the use of pre-stored passwords from Password Manager), I often have to re-enter the password because I mistyped it.  Some sites, however, lock an account for a user ID if there are multiple password errors within a short period of time.  This RFE would allow me to see what I typed and thus reduce the likelihood of being locked out.  

See Jakob Nielsen's "Stop Password Masking" at the cited URI for further justification for this RFE.  Nielson is a professional consultant on Internet useability issues.  

The extension Show Password On Input at <https://addons.mozilla.org/en-US/firefox/addon/6143/> is a response to my similar bug 232050 for the master password.  Per Nielson's commentary, these should not be extensions; instead, they should be inherent in the Toolkit.

Updated

9 years ago
Duplicate of this bug: 545939
(Reporter)

Comment 2

8 years ago
The Show my Password extension at <http://netcat.ath.cx/extensions.html> addresses this issue very well.  However, I strongly suggest that the capabilities of that extension be incorporated into Toolkit's Password Manager so that future changes to the Password Manager do not require corresponding changes to the extension.
Pretty sure we'd WONTFIX this but I'll leave it open for now.
Whiteboard: [WONTFIX?]
(Reporter)

Comment 4

8 years ago
There have been 91,266 downloads of the Show My Password extension.  This indicates user interest in this capability.  Yes, an extension CURRENTLY provides the capability.  This RFE, however, would mean that the capability would remain currently available whenever Password Manager is changed.  

Therefore, I request justification for why this might be WontFix.

Comment 5

7 years ago
This duplicates bug #368318.  A WONTFIX should be explained, considering the clear need.  Would a patch be welcome?
(Reporter)

Comment 6

7 years ago
This is a Toolkit/Password Manager bug (RFE).  Bug #368318 is against Firefox/General.  Thus, this bug report is more specific to what needs to be changed and also provides better justification.  Although bug #368318 is older, I would suggest that it be closed as a duplicate of this one.  

Note that the Show my Password extension (for passwords entered on Web pages, cited in comment #2) now requires an AMO override for compatibility with current versions of Mozilla-based products.  That would not be necessary if this RFE were implemented.
Whiteboard: [WONTFIX?]
This bug hasn't been WONTFIXed. The whiteboard is marked that way because I feel like we probably should WONTFIX it, but I wasn't sure enough to actually close it.

I still feel that way and think this is something best left to an extension at this point. The one mentioned in bug 368318 claims to be compatible through Firefox 7. (https://addons.mozilla.org/en-US/firefox/addon/unhide-passwords/)
Whiteboard: [WONTFIX?]

Comment 8

7 years ago
"I still feel that way and think this is something best left to an extension at this point."

If an extension could do it all, that could be OK.  However, the given extension
is more or less the equivalent of a greasemonkey script that changes the
input type=password to type=text.  Thus it may help some html, but does nothing
for HTTP-401 type password prompt dialog boxes or the like.
(Reporter)

Comment 9

7 years ago
An extension is at best a temporary work-around, especially when it needs to be modified or else requires an AMO override every time I update my browser.
There has been talk about allowing this temporarily like how IE11 does with an eye icon in the password field. While pressed, the password is visible. This isn't really a password manager bug though since it's not about saved passwords.
Component: Password Manager → Layout: Form Controls
Product: Toolkit → Core
Whiteboard: [WONTFIX?] → [DUPEME]
Duplicate of this bug: 368318
(Reporter)

Comment 13

5 years ago
Temporarily exposing passwords would be acceptable if this includes exposing while a password is being typed.  

In addition to the Show Password On Input extension for master passwords, I now have the Show my Password extension for individual passwords.  While this is somewhat helpful, the exposed password too easily becomes hidden again.  I would hope that an implementation for this bug report provides a less transient exposure.
Duplicate of this bug: 918538
Duplicate of this bug: 1111123
Summary: Option to Unhide Entry of Password → Option to Unhide Entry of Password (AKA "show password" equivalent for current mobile app/webpage idiom)
Blocks: 825533
Stephen, I heard that this was brought up in Whistler and that the only thing that's blocking platform folks from fixing this bug is icons. Do we have an SVG icon that they could use for this? SVG should allow for us to invert the color of the icon as necessary. Ehsan, is that all we would need from UX?
Flags: needinfo?(shorlander)
Flags: needinfo?(ehsan)
Do we want to use the native widget where applicable? e.g. Windows 8+

Comment 18

3 years ago
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> Stephen, I heard that this was brought up in Whistler and that the only
> thing that's blocking platform folks from fixing this bug is icons. Do we
> have an SVG icon that they could use for this? SVG should allow for us to
> invert the color of the icon as necessary. Ehsan, is that all we would need
> from UX?

Yes, I have already asked my intern Michael to look into this.

We will need help from the UX team on both the icon, and the interaction (whether we want to do something similar to native Windows 8+, or something similar to Edge on Windows 10, or something else).

I guess an SVG icon would work.

(In reply to Matthew N. [:MattN] (behind on reviews) from comment #17)
> Do we want to use the native widget where applicable? e.g. Windows 8+

Probably.  We need to investigate to see whether Windows provides the native widget in a way that we can draw it in the widget layer using instructions from the OS, or whether we need to imitate the native widget ourselves.
Flags: needinfo?(ehsan)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> Stephen, I heard that this was brought up in Whistler and that the only
> thing that's blocking platform folks from fixing this bug is icons. Do we
> have an SVG icon that they could use for this? SVG should allow for us to
> invert the color of the icon as necessary. Ehsan, is that all we would need
> from UX?

I am not entirely sure what is being proposed here or what icons would be required. Are we talking about adding a button to show passwords in all password fields? Would it be a toggle? A press and hold to reveal?

Ryan has done more thinking here than I have.
Flags: needinfo?(shorlander) → needinfo?(rfeeley)
(Reporter)

Comment 20

3 years ago
When I submitted this bug report, I anticipated an implementation not much different from the Show my Password extension from <https://addons.mozilla.org/en-US/seamonkey/addon/8016/>.  

If no preference was set beforehand to show passwords, the pull-down context menu should have a menu item for this.  Furthermore, the feature should not work until after the master password has been entered (unless, of course, there is no master password, in which case the feature would work without it).
(In reply to Stephen Horlander [:shorlander] from comment #19)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> > Stephen, I heard that this was brought up in Whistler and that the only
> > thing that's blocking platform folks from fixing this bug is icons. Do we
> > have an SVG icon that they could use for this? SVG should allow for us to
> > invert the color of the icon as necessary. Ehsan, is that all we would need
> > from UX?
> 
> I am not entirely sure what is being proposed here or what icons would be
> required. Are we talking about adding a button to show passwords in all
> password fields? Would it be a toggle? A press and hold to reveal?
> 
> Ryan has done more thinking here than I have.

Yeah, I think it'd be pretty safe to go with a press-and-hold, similar to what Edge does.

For default-styled password fields, Edge shows a grey background on hover, and a black background on mousedown, inverting the icon stroke. Password fields that have a custom background-color and text-color show the icon stroke in the same color as the text color and don't invert the stroke of the icon on mousedown.

Comment 22

3 years ago
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #21)
> (In reply to Stephen Horlander [:shorlander] from comment #19)
> > (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> > > Stephen, I heard that this was brought up in Whistler and that the only
> > > thing that's blocking platform folks from fixing this bug is icons. Do we
> > > have an SVG icon that they could use for this? SVG should allow for us to
> > > invert the color of the icon as necessary. Ehsan, is that all we would need
> > > from UX?
> > 
> > I am not entirely sure what is being proposed here or what icons would be
> > required. Are we talking about adding a button to show passwords in all
> > password fields? Would it be a toggle? A press and hold to reveal?
> > 
> > Ryan has done more thinking here than I have.
> 
> Yeah, I think it'd be pretty safe to go with a press-and-hold, similar to
> what Edge does.

What Edge does is different than what the native Windows form controls do, and I actually think that Edge's behavior is pretty crazy.  They only show the icon once and after you have used it, it goes away and there is no way to get it back AFAICT.  That is what I meant by designing the interaction.
I am not a fan of imposing browser UI on top of web content. Would a contextual menu help? A "Show password" toggle?
Flags: needinfo?(rfeeley)
(Reporter)

Comment 24

3 years ago
(In reply to Ryan Feeley [:rfeeley] from comment #23)
> I am not a fan of imposing browser UI on top of web content. Would a
> contextual menu help? A "Show password" toggle?

The Show my Password extension does indeed operate from a pull-down context menu.  However, it is now a toggle.  Instead, the user selects the password dots or asterisks and then right-clicks to get the menu from which "Show password" can be selected.  

A drawback of the extension is that the password is exposed only temporarily, often not long enough.  Another drawback is that the "Show password" item in the context menu appears only on even-numbered selections of the password dots or asterisks; an unsteady hand can prevent this from working.
Created attachment 8680838 [details]
Hide/Hide with divider

Some options for the contextual menu.
Created attachment 8680839 [details]
Show/hide no divider
Created attachment 8680841 [details]
Show/show no divider
Created attachment 8680842 [details]
Hide/hide no divider
(In reply to Ryan Feeley [:rfeeley] from comment #28)
> Created attachment 8680842 [details]
> Hide/hide no divider

I worry that the context menu will have low discoverability for the feature, but it will be a good v1. The 'no divider' option appears best to me, as the mockups with the dividers have a divider after almost every menuitem and it looks very zebra-stripey to me.
A good article about this topic by Luke Wroblewski.
http://www.lukew.com/ff/entry.asp?1941
I think the contextual menu is the right place for this. Putting browser UI on web content is problematic in so many cases (even though Apple now does it in Safari for passwords). I'm deferring to Stephen on this one, unless there are some big UX security issues I'm missing. The idea is that you can enable this per field and it is not saved for previous visits. Stephen, which above the above 4 options do you think works? (if any)
Flags: needinfo?(shorlander)
(In reply to Alejandro Moreno Calvo from comment #30)
> A good article about this topic by Luke Wroblewski.
> http://www.lukew.com/ff/entry.asp?1941

Love this article and referred to it heavily for password manager work, and even Firefox Accounts.
Note that if this ends up happening in a context menu rather than an in-textbox eyeball toggle/inline-whatever, then this means Firefox OS will likely need to do something different.  (Inactive/no-traction) bug 1111131 covers the Firefox OS case.  Additional context can be found in bug 1111131 comment 0 and in a dev.platform discussion thread at https://groups.google.com/forum/#!topic/mozilla.dev.platform/iNsK4egwRbI

For context, if you long-press in a password box on trunk Firefox OS, it activates a selection region with two handles and shows a hover menu with iconic buttons that represent "select all", "cut", and "copy".  (I suppose paste must show up in there sometimes too, but it's not happening for me.)  The icons are reasonably narrow, so I suppose an eyeball thing could be added there too.

Note that I'm not saying desktop and mobile have to do the same thing.  Just it would be nice ;)
See Also: → bug 1111131
Using a context menu is not very discoverable... because Twitter, Adobe etc. and even Microsoft Edge use an eye icon for this most users would be more than happy with that implementation.

If we are nervous about showing browserUI in content, which we arguably do with all controls, we could make it opt-in and / or customizable.

We could also have a small down arrow to show options a bit like Safari instead.

Of course, UX know best.
I'd be in favour of making password unmasking a browser preference, like pop-up blocking, that could also be controlled per site. Something for Control Center perhaps Aislinn?
Flags: needinfo?(agrigas)

Comment 36

3 years ago
(In reply to Ryan Feeley [:rfeeley] from comment #35)
> I'd be in favour of making password unmasking a browser preference, like
> pop-up blocking, that could also be controlled per site. Something for
> Control Center perhaps Aislinn?

I'm a bit confused at the problem we're trying to solve here. The original url when the bug was filed was pointing to evidence from Neilson that hiding passwords is a problem as 'users are typing'. This is a different use case than I think the end of this thread is talking about - revealing a password after it has been auto-filled for the user? 

Nonetheless, I don't think many users would discover a setting or inherently see the value or having auto-filled passwords revealed. Do we have any research showing people find it an issue outside of the manual password type in scenario?
Flags: needinfo?(agrigas)
It's a six year old old bug, but it's about giving users a way to unmask password fields on web pages like Edge does, regardless of where the passwords come from. It's ideal for someone living alone with a desktop computer that is secured. Masking passwords for this user offers little in terms of security.

Updated

3 years ago
Attachment #8680842 - Attachment is obsolete: true

Updated

3 years ago
Attachment #8680839 - Attachment is obsolete: true

Updated

3 years ago
Attachment #8680838 - Attachment is obsolete: true
Comment on attachment 8680841 [details]
Show/show no divider

Spoke with my UX team today and this is the desired design. Does not save per site, but that's something we can explore if it's received well.
Flags: needinfo?(shorlander)
Ehsan: here are some acceptance criteria to accompany the attached mockup.
1. When the user right-clicks the password field, Show Password item appears in contextual menu.
2. When the user chooses to Show Password, the password is unmasked, the contextual menu closes.
3. When the user reopens the contextual menu, a checkmark appears beside Show Password.
4. When the user chooses to no longer Show Password, the password is masked, and the contextual menu closes.

Make sense? Perhaps if this becomes useful, it can become managed like pop-up blocking permissions.
Flags: needinfo?(ehsan)

Comment 40

3 years ago
Oh, sorry I somehow missed this bug...  Thanks a lot for working on the UX design here!

Ryan, I'd like to take an opportunity to convince you against comment 23.  :-)  I believe that we can actually do a good job at embedding a browser-specific UI inside password fields, and as you probably know Edge and Safari have both successfully managed to ship such as UI.  That is also needed for native widget parity on Windows 10 (and also parity with our own browser UI which has been using similar UI in the password doorhanger prompts.)

Would you be available to discuss this in a meeting, or casually at the office at some point?
Flags: needinfo?(ehsan) → needinfo?(rfeeley)
(Reporter)

Comment 41

3 years ago
Comment #39 looks good.  For security, the default should always be to "mask" the password on each newly rendered Web page, including pages retrieved from the cache.  That way, a password will not be inadvertently exposed if the user forgets the current state of "mask/unmask".  This will automatically ensure that the setting is always "mask" when launching the application anew.
(In reply to :Ehsan Akhgari from comment #40)
> 
> Ryan, I'd like to take an opportunity to convince you against comment 23. 
> :-)  I believe that we can actually do a good job at embedding a
> browser-specific UI inside password fields, and as you probably know Edge
> and Safari have both successfully managed to ship such as UI.  That is also
> needed for native widget parity on Windows 10 (and also parity with our own
> browser UI which has been using similar UI in the password doorhanger
> prompts.)
> 
> Would you be available to discuss this in a meeting, or casually at the
> office at some point?

Let's chat! I'm here always. Bring your convincing pills.
Flags: needinfo?(rfeeley)

Comment 43

7 months ago
The current NIST guidelines state that "memorized secret authenticators" (passwords and PINs) SHOULD be made visible through an option.

https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
Duplicate of this bug: 1486213
The UX underwent some a11y training this week and discovered that a11y professionals recommend at all sites include a password visibility toggle.

I think that we should approach this in two ways.

In the short term, we should implement the contextual menu item the team approved in comment 38.

https://bugzilla.mozilla.org/show_bug.cgi?id=502258#c38

In the longer term (and I'll need help specifying this) we should allow web developers to access this same visibilty toggle through their own front end code. Meaning that those who already have a show password toggle implemented can simply improve the security without having to change their design.

In the far longer term we could include a password visibility toggle icon of our own, but would need to be careful not to overlap the UI of the site.
You need to log in before you can comment on or make changes to this bug.