Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Jakob Nielsen suggested it in 2009 (http://www.nngroup.com/articles/stop-password-masking/), and Luke W concurs (http://www.lukew.com/ff/entry.asp?1653), but are there any real-world implementations of such "visible password" fields?

Do you have examples or real-word experience of websites that show the password in plain text by default on registration or sign-in forms?

What are the issues? (apart from the obvious of someone looking over your shoulder with a note pad)

share|improve this question
2  
I assume you mean on desktop, because it's reasonably common on mobile devices to have plain text passwords. Certainly it's very common to have the last letter stay plain text for a couple of seconds before turning into a bullet or other 'hidden' character, and the user also has the control sometimes on mobile to show, all, part or none of the password in plain text. –  Roger Attrill Oct 11 '13 at 16:50
    
login.mailchimp.com has a checkbox to turn the password from blacked-out to plain text. –  kontur Oct 11 '13 at 17:59
    
Sure Facebook do it on mobile if you make a mistake due to mobile keyboards being a bit awkward –  ColinSharpe Oct 11 '13 at 21:28
    
@RogerAttrill Yeah - I'm mainly interested in desktop I guess - mobile websites would be great too. Or household-name mobile apps, but apps are generally sign in once and stay signed in forever which is a different experience. –  edeverett Oct 12 '13 at 13:57
    
@kontur, @ ColinSharpe Thanks, I'm really looking for examples that have the password plain text as default. –  edeverett Oct 12 '13 at 13:57
show 2 more comments

3 Answers

With all the concern about the security implications of someone "looking over the user's shoulder" I think we forget the actual user experience of showing the plain password.

A password is usually something you don't want known and most often it has personal meaning to the user. The obfuscated way of showing passwords re-enforces a sense of security to the user, by visually showing them that, as it were, even the interface they are entering their password to is unable to just read the secret token the user has chosen. Technically, of course, this is a whole different matter, but user interfaces communicate more than just technical facts or program state.

Traditionally, users are prone to use very personal pass phrases (against IT experts' advice, of course), like a loved one, some place of meaning, an item of affection they feel strong about... What I am getting at is that there is a cryptographic interest for the user to not want a password visible in plain text, but there is also a psychological or social aspect, i.e. "I don't want my reference to this 'dearest thing' on display", as it might not be something the user would openly admit to or endorse.

share|improve this answer
add comment

Smashing Magazine also covered this in their article:

http://uxdesign.smashingmagazine.com/2011/08/22/new-approaches-to-designing-login-forms/

At the bottom is the example of facebook who give you a plain text password field if you fail to get the password right on mobile login.

The obvious one is people looking over your shoulder, but this would actually be quite tricky, the hacker would need to get the email address and the website unless they knew the person plus we often interact in places where we are alone or where our shoulders cant be looked over.

Another less obvious problem is that it could give your site an appearance of being insecure, even if used in a secure environment, as passwords are almost always obscured and users might not necessarily know the technicalities of how browsers process them. Could you imagine a non-technical user who trusted an online bank that let them enter their passwords in plain text ?

The main issue is a balance of security (implied and real) vs. ease of use, particularly for repetitive actions like login - you might like to read this article for some more detail on this.

http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/

share|improve this answer
add comment

The use case for sign-in and registration are different. When you're signing in you know your password (unless you've forgotten it), so the main reason for using plaintext is to prevent typing mistakes. However when you're registering you're entering new data rather than confirming existing data, so the potential impact of a typo is greater. This is why registration forms typically have a second 'Confirm password' field.

I engaged with this issue earlier this year when I re-designed a login/registration form for a client. My preferred design pattern was the mobile phone one Roger Attrill mentions where the last letter of the password is shown in plain text for a few seconds before being masked by a bullet. I did find some js plugins that replicate this behaviour for desktop, but they all had some shortcomings so I didn't go with this approach.

The solution I went with reflects the difference between sign-in and registration behaviour.

Sign-in

Standard masked password input. This reinforces a sense of security (as mentioned by kontur), but is prone to unnoticed typos. The overriding reason I stuck with this pattern though was it matches user expectations.

Sign-in form

Registration form

Augmented password field with SHOW/HIDE button. No secondary 'Confirm password' input. This allows the user to show/hide their password, visually confirming what they've typed in. Being able to see your password means there's no need for a password confirmation field which keeps the registration form shorter and simpler.

Registration form

The jquery code for this is: (apologies to non-jquery purists)

// Show/hide plain text password
$('#pw a').on('click', function() {
  var $pw = $('#pw input.pw').not('.placeholder'), $txt = $('#pw input.txt');
  var isNowTxt = $('#pw').toggleClass('plain').hasClass('plain');
  isNowTxt ? $(this).text('Hide') : $(this).text('Show');
  isNowTxt ? $txt.val($pw.val()) : $pw.val($txt.val() != $txt.attr('placeholder') ? $txt.val() : '');
  isNowTxt ? $txt.focus() : $pw.prev().length ? $pw.prev().focus() : $pw.focus();
})

// and make sure the password value is correctly submitted
$('#pw a').closest('form').on('submit', function() {
  if ($('#pw .txt').is(':visible')) $("#pw a").click();
});
share|improve this answer
    
Hey @Mark_Chitty, good first post and reasoning. Usually implementation is out of scope on this particular stackexchange Q&A board, so you need not worry about actual code for solving a suggested problem :) –  kontur Oct 16 '13 at 6:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.