GNOME Bugzilla – Bug 681576
3.5.5: Lock screen shows password for a few characters / max 1 second
Last modified: 2012-09-19 21:55:02 UTC
To repeat: - Leave computer idle overnight - Have cron run all kinds of intensive disk IO things - Don't have an SSD, but go for a slow big disk - Turn on monitor - Press escape, then immediately start typing your password Actual Results: - For a few characters (2 or 3), I see the first few characters of my password and the disk is spinning like crazy - After maybe 0.5 seconds, it changes the characters into a normal password entry Expected results: - Never showing my password! I *cannot* repeat this by Lock the screen, so I'm guessing it is very timing related, or maybe I really have to wait for my system to be idle. I hope this can be fixed by looking at the code.
I was able to reproduce it just now. Basically I start typing immediately after pressing escape. The password is shown while the screen moves upward. As soon as the upward movement stops, the password box is hidden / cleared.
Ok, so the problem here is that we show the entry before we get the actual prompt from GDM (which in turn is slow because it has to spawn a process and bubble the various DBus message through several layers). I see (and implemented) two solutions here: - Don't show the dialog until it is completely ready - Optimize for the common unix local password case, and make the entry do the right thing. Both ways have their own problems, in particular: - gdm is slow, so going with 1) breaks the illusion of a dialog always there behind the curtain, even if we start creating it on drag start or esc key press - PAM is unpredictable, so going with 2) still has the "Password: " label fading in (as it could be anything, not just a password), and if you type fast enough you can finish the password with "Unlock" still insensitive - it has to be this way because we can't answer a query before we even get it Up to the designers to choose which one they prefer. Personally I'd go with 1.
Created attachment 221034 [details] [review] UnlockDialog: allow typing before the first question from PAM If the user starts typing right away, assume that the entry is for a password and don't clear it when the secret request actually comes.
Created attachment 221035 [details] [review] UnlockDialog: don't emit loaded until effectively loaded Delay showing the dialog until the conversation with GDM has started. This avoids showing an half prepared dialog, with the prompt fading in. OTOH, with this and a lagging gdm, the dialog appears after a while when pressing esc.
Can we get this reviewed ? Showing passwords in cleartext is kinda bad...
(In reply to comment #2) > - PAM is unpredictable, so going with 2) still has the "Password: " label > fading in (as it could be anything, not just a password), and if you type fast > enough you can finish the password with "Unlock" still insensitive - it has to > be this way because we can't answer a query before we even get it Could you queue up an answer to the query and submit it as soon as you get it?
*** Bug 683886 has been marked as a duplicate of this bug. ***
Created attachment 224283 [details] [review] UnlockDialog: allow typing before the first question from PAM If the user starts typing right away, assume that the entry is for a password and don't clear it when the secret request actually comes. Then, if the user completes typing, we also stash the answer and send it to GDM right away on the first PAM prompt. Ok, this allows clicking the first time. I'm less confident with this one, there is a risk of passwords ending up as usernames in syslog, but it's probably safe in common / known configurations, and that's where muscle-memory kicks in and makes this most useful.
Review of attachment 224283 [details] [review]: This looks good.
Attachment 224283 [details] pushed as 3d63202 - UnlockDialog: allow typing before the first question from PAM
we should probably tyr to get this type ahead feature in the login dialog too.
That makes sense. I wonder if it's better to have this login in the ShellUserVerifier.
*** Bug 684345 has been marked as a duplicate of this bug. ***