No “type=password” fields?

June 25, 2009

Looks like Jakob Nielsen is at it again.  The man certainly knows his usability stuff, and although he’s often controversial, and seldom “wrong”, he does put out some “doosies” every once in a while.  His latest column on web usability calls for people to stop using password masking – effectively not using the “type=password” attribute on input fields.

Now, he puts out a good argument – there’s certainly times when it’s much easier to enter a password (especially on a mobile device) when you can see the characters you are entering.  Also, knowing you are entering in the right characters probably will mean less errors and people using stronger, more complex, passwords.  There’s also times when you know you want to protect from shoulder-surfing, and a simple checkbox could re-enable password masking on the few occasions it’s really required. All very valid points.

My worry is though that without the “type=password” attribute, browsers won’t know that it’s a password field and won’t protect it accordingly.  All browsers cache data, depending on settings, to “help” users when they have to re-enter information, but certain data should always be discouraged from being cached – it’s just too easy to dig it back out of the browser [PDF link].

Liberal use of the “autocomplete=off” attribute on these forms (or, non-standard[ly], on the fields themselves) does discourage browsers from caching that data, but in my trawls around the web both as a user and a security tester I see it used very infrequently.

Having the “type=password” is a way of “default denying” as all web developers know to use this field for passwords and the browser just takes care of the rest by not caching these types of fields, and even providing a warning if you are going to send them in clear text over HTTP.  Developers don’t even have to think about it – they know it’s a password, so a password field they use, and leave the browser to provide sensible default protection.

Unless we are going to change the way that browsers render “type=password” fields, and leave the web developers to use them as intended, but with subtly different UI (opt-in of course), I have to say this is a non-starter for me.  I certainly don’t want to see developers “faking it” with JS/AJAX and modifying input box types on-the-fly because once again that can introduce insecure behavior if you’re not really careful.  We have a default “fail closed” state in password fields and modifying it, calling for it to be changed, or just plain removing it I feel will introduce issues because there’s already a built-up expectation of the working-model – developers don’t change their working model or practices all that easily.

Oh, and the other point Jakob makes about reset buttons – I fully agree – kill the buggers buttons.  Thing is though that I rarely see them any more so I guess we are getting a little better (in UI at least).

UPDATE: Looks like this has hit Schneier’s site, and as he gets obviosuly gets more viewers that I do, it’s good to look at the comments.  Most people seem to agree in leaving the password field alone.

Posted in Musings, Security