Should the password field be cleared after an unsuccessful login attempt?

Question

Let's assume following workflow for logging in

a) On a device with keyboard:

1. I type my username and password
2. Press enter
3. [realization] I made a typo
4. Password field is cleared: not a big deal, I can type reasonably quick

b) On a device with touchscreen

1. I type my username and password
2. Press "logon"
3. [realization] My password is "password2013", not "password2012"
4. Password field is cleared: now we are talking - I would rather have my * * * * * values so I could just correct single character rather than typing whole password again, on some occasions even my username is cleared which is a complete waste of time

Few questions here:

• Is it valid user experience point to have asterisks retained in the password field?
• Is there any reason to clear field values or is it just pure laziness not to feed them back after round-trip to server?
• When using AJAX forms - would you preserve or clear the values?
• Does it make sense to use hybrid approach - preserve values and clear them after arbitrary timeout?

Is there a security risk to leave password as * * * * * ?

I leave my computer, attacker sees my open tab and can retrieve my wrongly typed password: http://jsfiddle.net/stefek99/2Uh9T/ BUT [logic kicks in] if an attacker has access to my computer there are more efficient ways of harming me than peeking the wrong password :)

Existing examples:

• Windows 7 logon screen - password is cleared
• Mac OS X logon screen - password is preserved

Should the password field be cleared after an unsuccessful login attempt?

Answer 1

It should be cleared.

It's not that uncommon a situation where a user enters the password, hits "log in", and wanders off for a bit, doing other things. It has certainly happened to me where I have attempted to log in to GMail, and come to know of the failed login an hour later. There are also systems (sudo apt-get -y install comes to mind, though in this case the failed password attempt isn't retrievable) where you need to just authenticate and then forget about it --

In the GMail situation listed above, someone could easily get the plaintext password (well, the typo'd version, but usually it's easy to fix that) if I got up from my computer in that hour.

if an attacker has access to my computer there are more efficient ways of harming me

There's much more havoc that can be wreaked if an attacker knows the password than in the case where the attacker is just logged in, usually.

However, this really depends on the system. For a desktop login screen, it doesn't matter much as long as the password field isn't copyable. For online services, it matters a lot more.

Answer 2

Not clearing the password field has the unfortunate side-effects that some user will just assume that "meh, it didn't work this time" and will submit the password again, unmodified. It is part of the average human psyche that when something goes wrong, the user will first think that it is someone else's fault -- i.e. that if login failed, then the server is responsible, not their own password entry.

This behaviour implies more work on the server (if the server stores password hashes with slow hashing, as it should, then this increases the computational burden on the server) and is at odds with some auto-lockout policies (when too many wrong passwords are entered, the account is locked or at least disabled for a few minutes, as a protection against online dictionary attacks).

Security issues with reflected passwords are what @Manishearth discusses: in a generic way, a password is sensitive and therefore it is considered best if the user can control the lifetime of any written copy of his password. If the server sends back the password to the client in some cases, then the user can no longer make sure that no written copy of his password is accessible at some time. This is not a very serious issue (it takes a rather special situation for it to become relevant), but still worth thinking about.

For these reasons, I recommend clearing the password field. Touchscreen users be damned; nobody forced them to buy an iPad.

Answer 3

I don't think it would take a terribly sophisticated "hacker" to figure out that document.forms["login"]["password"].value; is a great way to steal a still-typed-in password. Granted there are worse things they could do with your computer like that, but I would say it's your responsibility as the user to make that decision; the site operator should make things as secure as possible.

Besides, if you're on a banking website, there aren't many other things someone could do that would make life worse for you...