gtk3-3.9.10 has, in https://git.gnome.org/browse/gtk+/commit/gtk/gtkentry.c?id=4b5a389e88af7e7a1fa9e33294642dcfbc2832ec , hardcoded echoing password characters on the screen. (The last character is shown as you type, while the rest are masked) While it may be the case that some dialogs are fine with this setting, others are IMHO less so. Could we perhaps not default to it globally, but let those specific dialogs or applications that desire it set it? Perhaps we could set it only for non admin users? Failing that is there any way to opt out and return to the fully masked behavior, either globally for all gtk3 password dialogs, or per application? Thanks for your consideration...
*** Bug 997014 has been marked as a duplicate of this bug. ***
*** Bug 984320 has been marked as a duplicate of this bug. ***
There is a large difference between hand-held and a desktop computers. Hand-held computers have a software keyboard with high error rate -> you need to see what you type. They are small and you hold them close, so you shield the display with your body. You are also often standing or in motion, so you have awareness of the surroundings. On a desktop computer, you shield the keyboard with your body, but not your 27" screen. In an office environment, there are usually number of people behind your back all the time, and anyone can be watching your screen at any time. With this setting, the security of your password is drastically reduced. I wouldn't be willing to type in my passwords when being in the office. Recently GNOME raised $20,000 for improving privacy and security [1]. This goes directly against the campaign. Even more, it is implemented in a time where privacy is an extremely sensitive issue (the NSA spying case). CCing William Jon McCann. William, can you please explain why this is a) hardcoded b) enabled by default on desktop, and not just on handheld devices? [1] http://www.gnome.org/news/2013/07/gnome-raises-20000-to-enhance-security-and-privacy/
Oh, by the way, this is what Microsoft solution looks like: http://blogs.technet.com/b/next/archive/2012/11/12/little-details-windows-8-passwords.aspx#.UhcaGR-Knlc I find it highly superior, especially for desktop use. It solves the problem (users have a simple way to verify their password) without compromising security. Please note that it still can be disabled globally, which is very important for corporate usage.
(In reply to Kamil Páral from comment #5) > Oh, by the way, this is what Microsoft solution looks like: > http://blogs.technet.com/b/next/archive/2012/11/12/little-details-windows-8- > passwords.aspx#.UhcaGR-Knlc > > I find it highly superior, especially for desktop use. It solves the problem > (users have a simple way to verify their password) without compromising > security. It also shows the whole password instead of only the last character. So I can check the password against a plaintext on paper or in another window, let a friend recheck that the wifi password is correct, etc. All of this while remaining secure in ordinary usage.
(In reply to Miloslav Trmač from comment #6) > > It also shows the whole password instead of only the last character. So I > can check the password against a plaintext on paper or in another window, > let a friend recheck that the wifi password is correct, etc. Continuing this line of thought why not to display passwords permanently on a panel bar? That would make such checking definitely easier and it surely would be consistent with this whole concept and approach.
Yesterday a colleague of mine learned my bugzilla password, because I was not expecting this feature. I showed him a crash on my screen, and then started to type my bugzilla password in the abrt/libreport window in order to report it. I did it head down, because I have a complicated password and I need to watch the keyboard. Since I move my hands a lot because of some special characters, it adds half a second delay to many keystrokes. The total outcome effect is that my password was nicely readable to my colleague, or anyone else watching my screen. If this is not a security problem, what is? Moreover, I cannot effectively report bugs in an office environment, since the test machines are physically close to each other and someone is at least partially watching my screen most of the time. This is a real showstopper for someone who needs to fill in his bugzilla/other password a dozen times a day in a shared environment.
(In reply to Kevin Fenzi from comment #0) > gtk3-3.9.10 has, in > https://git.gnome.org/browse/gtk+/commit/gtk/gtkentry. > c?id=4b5a389e88af7e7a1fa9e33294642dcfbc2832ec , hardcoded echoing password > characters on the screen. > > (The last character is shown as you type, while the rest are masked) > In addition to the 'lightdm-gtk-greeter', this has had the effect on the 'polkit-gnome-authentication-agent-1' also. Such a childish play, happy campers. However it is resolved, commit 3442933dd7ea6c9f411a021a19202b91cc090610 Author: Matthias Clasen <mclasen> Date: Sat Aug 31 00:14:58 2013 -0400 Revert "Deprecate and ignore gtk-entry-password-hint-timeout" This reverts commit 4b5a389e88af7e7a1fa9e33294642dcfbc2832ec. This change caused considerable concern about accidental leaking of passwords, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=706563 https://bugzilla.gnome.org/show_bug.cgi?id=706873 https://bugzilla.redhat.com/show_bug.cgi?id=994237 We may have to do something else for password entries, such as the windows-style 'peekabo' icon. gtk/gtkentry.c | 19 ++++++------------- gtk/gtksettings.c | 6 ++---- 2 files changed, 8 insertions(+), 17 deletions(-) I tested this and it works well as it should. Bravissimo Mat.
Thanks Matthias. The commit landed in master branch, but since there's no gtk-3-10 branch yet, I assume we should see the change in the next updated package for gtk. Closing as Closed Upstream. If this is not fixed soon in Fedora, feel free to reopen. Thanks.