No problem with passwords - A comment to Lyle Mullican

This article has been republished, due to a problem with spamming of the comment field. The problem is now solved. Ola Imerslund

February 9, 2010 Lyle Mullican published his article called The Problem with Passwords on the A List Apart web site. His article discusses how to design more usable password fields in web page forms, in the aftermath of Dr Jakob Nielsen's article Stop Password Masking. Mullican also gives two examples on how one can accomplish that, the first of which I provide more completely below.

The two form examples provided in the A List Apart article are mere examples of how demasking a password would typically look like. They don't show how browsers actually act when you submit your logon details to a web site. The real problem with password demasking is not the demasking itself - the problem is that users rarely can decide whether to use it or not.

Of the two examples provided in that article, I would not even consider example two to be realistic to implement on a web site. Just imagine that you are in a business meeting and your computer's laptop is the one shown on the projector, and you have to log on to a website that has implemented example two as their solution... Either you type incredibly fast, or your password to that site (and probably other sites too?) is no longer a secret.

I will therefore comment only on Mullican's example one. Since the technique basically is to change a password field to a text field, the following security and usability issues emerge once the user submits her password after choosing to see it in plain text:

  1. Since the browser doesn't recognise the password to be in a password field, it doesn't ask the user whether she wants to save it upon submitting.
  2. And what is worse: The next user on the same computer can enter the previous one's user name in the user name field, check the `Show password' box and double click in the password field. Most browsers will now reveal the previous user's password - in plain text.

In my revised version of Lyle Mullican's example one, there is actually a user name field and a (fake) `Log on' submit button, to demonstrate the mentioned effects clearer. Go test example 1 yourself!

If plain text fields were as good for handling passwords as password fields are, password fields would probably never be invented in the first place.

A better solution than Lyle Mullican's example 1 would be to let browsers continue password-handling in their usual way - at least until browser design/html design on password handling changes.

In my following example we will keep the visual design of Mr Mullican, but still let browsers understand that the password being typed is a password.

The arithmetics would work approximately as the following:

  1. When the user checks the `Show password' box, a new, empty text field is created, and the original password field is hidden behind the new field.
  2. As the user types her password in plain text, the input in the new field will will be inserted in the invisible, original password field.
  3. When the user submits her data, or chooses to not show her password anymore, the text field with the password disappears.

Feel free to test my example 2 yourself!

By letting a part of plain text password field's name be a timestamp, its name will be unique each time it is created. This way browsers will not show what has previously been typed in the plain text password field, because it has technically never existed earlier.

Neither the user herself or anyone else, at any time, may reveal a previously typed password in plain text. This way, if the user has a `friend' on her side who ticks the `Show password' box before she can react, or if she herself accidently ticks it on her way to the submit button.

No password is shown, no damage is done - and the trust of your users is preserved.

Write a comment

  • Required fields are marked with *.