Page MenuHome GnuPG

pinentry option to see the password in cleartext
Closed, ResolvedPublic

Description

It would be nice if pinentries would allow optionally
to show the passphrase /password in cleartext to check the typing.

This was proposed and initially discussed on gnupg-devel in 2015-05 here is the thread
https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/thread.html#29790

During the gpg4all contract implementation for pinentry-qt and pinentry-gtk
is now pending, revisiting the issue. I am opening this issue to document
the design considerations.

The current patch has a warning dialog when going from hidden -> clear state
and at least one character is in the hidden field.
Feedback from Bernhard Reiter, Emanuel Schütze and Sean Engelhardt is
that this warning dialog seems to be suboptimal.

My argument to go without the warning dialog:
The common case is that people want to see the passphrase when
activating the option. This would correspond to an often used
user interface principle: Design for the common case.
(e.g. see Principles in Jeff Johnson's http://www.gui-bloopers.com/toc.php)

The warning dialog would be safety switch if a user
does not now the button or accidentially activates it.
This seems to be a rare case and the damage of losing information
about ones password is easily revertabel, either press the button
again or just change the password afterwards. So the safety switch
would be hinder the common case and the rare case has a recovery option
even without it.

Event Timeline

bernhard added a subscriber: bernhard.

My suggestion is also, to seek for an icon that is more self-explanatory.
Actually I would like the "gtk_switch" gui component, though Werner is right
that it takes up a bit more of space.

Some people are used to pinentry and have a common keyboard-based type, tab, hit
enter workflow.

Please make sure that this workflow doesn't accidentally switch their password
to visible when this change is implemented.

Daniel:
Thanks for your comment and adding the use case. I saw your suggestions
on the list like changing the tab order.

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

@dkg: I have been thinking about your use case:

Some people are used to pinentry and
have a common keyboard-based type, tab, hit enter workflow.

I wonder about what fraction of people we are speaking of.
In many applications, just like pinentry, you can just hit "enter" right away
so there is no need to first hit "tab". First hitting "tab" does not make sense
for these kind of dialoges.

Then in some implementation like pinentry-gtk2 0.8.3-2,
this does not work right now, because the next tab is "cancel" which users then
would reach. So it depends on the standard for dialog windows where the
ok and cancel buttons are. Was there any problem report on pinentry-gtk-2?
I am not sure if any pinentry-gtk-2 user actually had this problem?

On Thu 2015-10-29 04:34:03 -0400, Bernhard Reiter via BTS wrote:

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

I think if there was no risk of tab order confusion and if the button
has a clear tooltip (mouseover text) that explains the risk, i could
live without the warning dialog.

--dkg

Btw. The Windows 10 login screen implements this as a button that you can not
tab to and only shows the password for as long as you keep clicking it.
It also disables / hides the show password button once the password entry field
loses input focus.

They use a heavily abstracted eye icon and no tooltip. Probably with the
rationale that if a user clicks there and it shows the password
(unintentionally) he can quickly release the mouse button again before someone
can read the password.

Hi!

@dkg:
Can you tell me more about your tab-return use case? Do you have hints/personal
observations about how many people are affected?
In the gtk2 pinentry this did not work so far (See my T2139 (bernhard on Oct 29 2015, 04:42 PM / Roundup)) other
implementation do not seem to allow it (I've also tested kdm login screen)
and it does not make much sense either when you can press "return" right away.
So to me it is still unclear how many people are affected.

@aheinecke: Thanks for contributing another case.
I think it is a good solution for a system login screen, where a login-change
probably is harder to do.
I think this slightly changes when you think about passphrases for pinentry
that may get entered less often and some people keep a backup on paper (which is
actually good under some circumstances) and I would claim that a passphrase
change on a key on average is easier to do than a system password.

@werner: You wrote that you've checked some other implementation, it would be cool
to have a list of those. Screenshots would be even better.

@all, my current design ideas are

  • to have a text below the entry field, close to it, saying "show password" and a on-off switch or second best a check-box, third best a button.

Rationale: Because the space requirement is mainly in width. An on-off switch

probably has the most natural mapping, but this depend on the overal GUI design
of the system. On some a real slider-switch may not be available or look alien,
then we should use what ever users will recognise as an on-off thing.
The text is much less work than to select/design an icon and it uses
less height.
  • It is okay to have that in the accessibility tab list, even after the entry field, because I personally believe that a lot more people want the natural order when using tab at all. Right now the data for how many people actually have the tab-enter habit is unknown, maybe Daniel can help us out here.

@dkg,
what do you think about T2139 (bernhard on Nov 02 2015, 10:09 AM / Roundup)?

Bernhard:

I've tried out KDE 5 and noticed that the standard password dialog there already
has such an option. http://www.aelog.org/password-visibility-in-kpassworddialog/

My strong preference for Pinentry-qt would be to make it similar. As a unified
UI adds value and pinentry-qt is afail most often used with Windows and KDE
desktops. And the solution outlined in the link above is also very similar to
the Windows 10 password entry.

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

Would this be acceptable for you?

(2nd try, the mailinterface failed for me.)

http://www.aelog.org/password-visibility-in-kpassworddialog/

Good that you found it.
In the comments Bogdan has a point.
The screenshots also do not look convincing, but I agree it makes sense to be
consistent there. Could we also get a screenshot about this implementation
for Windows 8 they are talking about?

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

As gtk-pinentry

  1. currently does not allow tab-return
  2. and it does not make sense as a workflow
  3. we are lacking further evidence if there are users that still use this for a password entry. (Not response by dkg.)

I'd say the discussion on the mailinglist is fully superceded.

In my view we should
a) design it close to pinentry-qt, because it also will be used on Windows

mostly and the consistency with other Windows password dialogs has a lot of 
weight

b) Look at other wide spread gtk-dialog for this functionality and use

   the better design considerin Bogdans comment with a "switch".

The icon could possibly used in both implementations. (If the license allows
this. Oxygen used to have a bit less practical licene coming with it.)

Best,
Bernhar

pinentry-gtk-2 does currently support the tab-tab-enter use case. Using 0.9.6-4
from debian, i can use tab to cycle between the textentry dialog and cancel and OK.

I see the same behavior from pinentry-gnome3 (0.9.6-4), tab workflow is:

  • textentry
  • Cancel
  • OK

for pinentry-qt (same version as tested above) the tab ordering is:

  • textentry
  • OK
  • Cancel

That said, i agree that i'm the only person who has raised this, and i'm
perfectly willing to be retrained to use more efficient keyboard flows if
they're presented to me. So if you want to go ahead with the current plan,
that's fine with me.

I agree that consistency with common UI patterns on the platform of choice are
worth emulating -- we don't need to invent or maintain our own UI patterns that
are idiosyncratic to GnuPG.

So if you want to go ahead with the current plan, that's fine with me.

Thanks for your feedback.
I was wondering specifically about the use-case when you want to enter
and "ok" the passphrase. The regular flow for this as I understand it would=
be

  typing the passphrase and then "enter" or "return"

I think it is okay to have "tab" cycle between options, but including the=20
option of toggling visibility, because somebody who want to enter the=20
passphrase would (in my understand) always do the above flow and not=20
tab-tab-enter.

Ready for implementation by Andre.

When this feature becomes available, then we should probably disable
"gtk-entry-password-hint-timeout". See the following Debian bug report for details:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801757

I've implemented this for Qt now.

The Qt5 variant with breeze icon theme looks like the attached screenshot. This
is how it will look on Windows and for KDE plasma 5 users.

If the Qt version is too old (The API for the line edit action was added in
Qt5.2) or there is no icon for the visibility actions it falls back to a textual
checkbox.
This also avoids licensing problems with the icons as the icons are loaded
through QIcon::fromTheme.

Fallback variant. (Qt5 Version with XDG_CURRENT_DESKTOP=GNOME)

The checkbox comes after the cancel button in the Tab order and will not
activate when pressing enter.

This is how I'll add it to the GTK variant now.

Neal: I've commited this with: 71b51e02cf20174ba7144765e985f7e889eaa429

The Make passphrase visible is in the tab order after the line edit. I don't
know how to best change this in GTK and the "Save passphrace using libsecret"
button would have the same problem.

I don't think it's a real problem though as you would have to tab + space to
make the password visible. Tab + Enter would just accept the dialog.

If you think this ok you can set this issue to resolved. You can also change the
setting you mentioned in T2139 (neal on Dec 07 2015, 10:09 AM / Roundup) . I don't know how. :-)

We might want to change the strings in gpg-agent though. I would prefer: "Show
passphrase" instead of "Make passphrase visible".

Better screenshot of the fallback showing a real call by gpg-agent instead of a
"getpin"

I though we agreed that a watching eye is not a good icon for various reasons?

For the GTK version I already proposed a different layout:
it is still available at https://wiki.gnupg.org/ScratchWK . That fallback
solution tales away to much real estate

No string changes in gpg-agent please.

I know your first draft.

But from the discussion here and back then I took that draft to be no longer up
to date and that the MessageBox Question approach with small icon buttons is not
wanted.

I also don't know where we agreed that an Eye icon is a bad idea for this action.
This icon in similar to the one of the Windows Login screen and the same one
used in KDE. So it is recognizable for this action.

If you strongly favor the Message box variant I can change it to that.

Am Donnerstag, 14. April 2016 16:24:59 schrieb Andre Heinecke via BTS:

But from the discussion here and back then I took that draft to be no
longer up to date and that the MessageBox Question approach with small icon
buttons is not wanted.

That was also my impression.
I think the most important design criteria is: Will users understand
the GUI and being familiar with the icon "language" is really helpful in
having a good chance of a natural mapping.

I've now pushed a patch to the GTK variant based on werner's original work with
the message box and the string button labels.

I was unable to get the tab order working correctly so that the visibility
button comes last in GTK. I've tried it with gtk_container_set_focus_chain but
it did not work as expected. When set on the wvbox it disabled tab changes
altogether. When set on the cbbox or bbbox it somewhat worked (e.g. when I
removed a widget from my list it was no longer tabbable) but it would not add
the repeat edit and the visibility toggle button although both were part of my list.
Probably a problem because of the sublayouts?

I noted this in the code so if someone wants to change that you are welcome :-)

werner removed a project: Restricted Project.