User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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)
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.
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/
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.
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.
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.
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();
});
