To star or not to star…that is the question.

This blog post is more than 4 years old, so the content may be out of date.

A too-long-to-discuss-on-twitter post…

I noticed Jeremy Keith and Jeffrey Zeldman discussing and retweeting view-points on whether passwords should be hidden/starred-out (on websites).

Zeldman:

"Make passwords visible by default, with a toggle to hide. Blackout dots in password entry fields are security theater." @adactio

I'm not sure that I agree. Shoulder-surfing is a non-existent problem on websites, because at the moment, there's nothing for people to shoulder-surf.

Jeremy responded to my comment with a reference to an experiment that displayed the password when entering password fields.

Adactio:

@manarth http://storify.com/lukew/yahoo-display-password-test…

That's a fascinating experiment, but is limited because the app in question is a mobile app. The form factor for mobile devices is much less susceptible to shoulder-surfing than desktop computers, and they are inherently personal, so less likely to be a shared device. I'm not sure that the results of that experiment can be extrapolated to websites in general.

Jeremy and Drew McLellan went on to have a discussion of other security benefits of password fields - one is that generally, browsers won't store the password in the history. This means that if you use a regular text input (and obscure the password with some other technique such as JS) then the password might be stored in the browser's history, negating the security benefits. Jeremy suggested that using autocomplete="off" might address that issue. I suspect he's correct - it may well prevent the password from being stored in the browser history - but it would also prevent users from using the password-autocomplete. Personally, I get irritated by sites that turn off autocomplete for usernames and passwords. Understandable for my bank, but less so for, say, a forum for a PHP framework.

We already have a semantically-correct input field for passwords. Yes, most browsers will obscure the contents of this in some way. If this is not the best UX, then the place to address this is in the browsers, rather than by cumbersome hacks to circumvent this (although that said, maybe it'll take a critical mass of circumvention before the browser developers depart the status-quo).

I can imagine two main scenarios where a by-default-display policy would expose a users password:

  • Shoulder-surfing:
    Less a problem on mobile devices, but on desktops - perhaps a shared office, or an internet cafe - passers-by could view the password. Many users will simply accept the default, so even if there is a toggle-button to hide the password, it may not be used.
    Even if there aren't any passers-by, the password could still be captured on camera - for example, CCTV. This is perhaps an extreme premise, because if the site is untrustworthy, then a keylogger on the computer could achieve the same thing. But perhaps this might apply to using your own laptop in a Starbucks?
    Theoretically, you could simply click the Hide password button. But many users will simply accept the defaults, and even the security-concious might be on the lookout for people, but miss the camera in the corner.
  • Presenting to an audience:
    I've given plenty of conference talks where a question from the audience has prompted me to open a website, to demonstrate a topic. If I went to a website with a login prompt, and autocomplete entered my password, my password would be visible to a large audience. Many of whom would have internet access, and might decide to have a little fun with my account.
    Displaying passwords by default, and autocompletion of passwords, are mutually exclusive.

So I'm not sure we're ready for exposed passwords just yet. And perhaps we never will be. But I firmly believe that if we're going to change it, the functionality should change in the browser, not in the HTML. We've got a perfectly usable semantically-correct password field, so let's use it.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <apache>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo]. PHP source code can also be enclosed in <?php ... ?> or <% ... %>.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.