Luke has written another interesting take on the topic of showing and hiding passwords, especially within the context of mobile. Given that our goal is to provide a consistent experience throughout though, I think this is a great big picture topic. I would love any thoughts (for or against) on what Luke has proposed, citing any studies or experiences you might have had.

exquisitetweets.com

I'm all onboard with not masking the password input. Like Luke says, on a mobile device it's easy to obscure from any prying eyes.

And when people are creating a new account or changing a password, you don't have to ask them to type it twice to confirm a match. Double win!

How do you guys respond to the person who says that showing a plain-text password is a security breach. Always.

Is it? Is there truly a security gain by hiding a password or is it just a perceived gain?

Neilsen has this opinion: useit.com

I'd like to see more data behind it though.

They might be getting confused with *storing* a password in plaintext is a security breach (and it is, it should be hashed instead :)

@mathew — No the argument I've received is that the fact I can shoulder-surf a password, reading either a full or partial password (and given that people tend to remember logical passwords: names, dates, something centered upon themselves, one could most likely discern a password with a handful of characters); THAT constitutes a security breach.

How would you respond to that?

I can clearly, almost unequivocally state that you never need to mask a password field in mobile. And you should not automatically do so in desktop, if that matters anymore. I formally stated this as a key part of a pattern, here:
4ourth.com

I think the fundamental issue, the reason that the community as a whole doesn't have an answer, is that:
1) UX does not have a background in Design for Security (yes, that's a thing)
2) Security guys focus on technical measures, with an only fairly recent understanding of social and psychological tricks and pressures. They tend to miss UI/IxD measures.

(continues... why can't I type long answers?)

So, a bunch of thoughts and notes in the order they occur to me:
- Security (and legal, and so on) tend to over-react. If you ask if a protective measure is needed, they always say yes. Ask the question differently.

- Matthew's comment is close. A lot of security guys conflate the various issues, so are answering the wrong question. Sometimes, they mean storage, or passing back a password on a summary screen. Yup, I've had developers misunderstand that -- I had a screen where I summarized all settings. Some items were partly or completely masked like credit card or password, of course. The developers read this as "pass actual value to presentation layer, then mask." ... (continues)

...Of course, and thankfully, someone caught this. Of course you don't release secure info unless you need to.

- "Best practice" is rolled out all the time as a reason. It's an excuse as most of this is just "common practice." It's not best unless you can prove it.

- We are a lazy culture. Why clean and maintain when you can buy a new box? We mask passwords and call it a solution. Look around. The products with annoying-to-enter passwords also tend to store them in plaintext, have bad data retention policies, and keep a unique key for you in a cookie.

(continues)

- Security is about risk /management/. Not elimination. Stop & think about that. There is No Such Thing as an unpickable lock, un-crackable safe, or unbreakable code. At all. It's a tradeoff in time, detection, convenience, and cost. My house can get by w/ mediocre locks, or none in use, because I have neighbors (who have confronted friends who "broke in" when they forget the key while house sitting). And risk is not all initiated by evildoers. The fire safe in my basement can have a relatively low rating, because of where I placed it, and the fire department has a low response time. If I was in the country, I'd need a fire safe that can withstand hours of fire as maybe no one notices, or it's a wildfire and no one can respond. (continues)

- What I have drifted into here is saying that security is also layered. For technical security, it's more important to do things like notify and log. If the user changes the password, send an out of band message about that, and let them escalate it. Take the fire safe: I rely on out of band notifications (smoke, flames) and reaction of other systems (firemen, hoses, water) to solve the issue. I can save money, have a smaller unit, that I can install myself (cost, convenience) in exchange for resistance time as other systems will (I hope) save me.

(continues)

- Convenience: Is not just to make sure you meet the key risk of "keep my job" or "company stays in business," but to avoid other issues. What if the password is so difficult to remember and has to be entered so much that users write it on a post it? Reducing password reliance can increase security. Okay, back to masking: unmasked passwords can be typed faster, with fewer errors. Secure

(continues)

- Shoulder-surfing may not exist. Even on desktop, but especially not on mobiles, due to size, and the way people use them. I can find no evidence it is widespread and no one has ever shown me it is (see next point). Continuing the previous point, if it's easy to enter, then people may use it more. Pattern passwords are used more heavily to lock phones than numeric passwords. That's a bonus. If you are sure that shoulder surfing does exist then the speedier entry on unmasked fields is a good thing as it makes keyboard watching harder (and there are lab demonstrations of keyboard entry being observed/listened to; maybe the CIA does this, but it's not a casual issue).

(continues)

- Paranoid lawyers, security professionals and government regulators let me do it. A lot of the places I have been allowed to design registration and signon schemes have solid oversight. I don't slip it through, but explain it, then get signoff. Every time. See "lazy" and "best practice" above: the only times it gets rejected are random BAs, Product Owners and Developers.

(continues)

If you missed my tweet in the original topic, the first time I implemented this was during the CPNI revisions (after all the "pretexting" scandals) the FCC mandated. Long, interesting story but for another time. It was for a registration form, as we had to get all 20-some-million customers to re-register with all new credentials. We did user testing, got legal/security/regulatory signoff, and then... worked perfectly. We got weekly reports from customer care, etc. and it never ever had one complaint, or anything. Huge completion rates, and I certainly never heard of a security problem with it. Happy customers + secure enough = good solution.

[END]

@Steven — Thanks for the lengthy response. Give me a little time and I'll respond with any further questions I might have. Thanks!