I just ran across LukeW’s post on showing passwords by default on mobile apps. It’s an interesting idea, at least something to consider. However, it seems like it is a bit self-contradictory. On the one hand, he says that showing the password is important because people can’t see it when entering it, that is, because they are looking at the keyboard, they can’t easily see the typical delayed-show characters. Then he goes on to say that the * approach doesn’t really hide the characters being typed because the touch keyboards show what is being typed really largely.
To me, this begs the question, if it is so easy for others who might be looking over the shoulder to see the keys being typed, how is it so hard for the person looking straight at the keyboard to see them? A bit contradictory to say the least.
Now I’m all for improving usability, especially for notoriously problematic things like this. But it seems to me that this is, at least, a questionable practice to be encouraging. It’s akin to saying that because there are lock picks, you shouldn’t bother locking your doors. In security, nothing is guaranteed 100%. It is all on a spectrum, and many things are simply deterrents. Masking the password is one such deterrent.
On the other hand, it is in the context of mobile, and one could argue that yes, it is easier to shield the screen in most cases than it would be with laptop or desktops, as Luke does argue. There’s something to be said for that. The flip side to that is that mobile contexts are more variable and often have more potential security threats than even you know about. Sitting at your desk in your room at home or in the office, it is not very likely someone will be looking over your shoulder (that you’d be worried about). Standing on a subway? Who knows?
As a software architect and interaction designer, I just can’t endorse this practice as a good default. Even if your app doesn’t have sensitive information, it’s highly likely that users will use the same password they use for other things with more sensitive information, and the same email/login. So while you may think you’re only chancing your app’s data, you are not. If you want to let people confirm their password is right, go with the optional show password toggle. Don’t show it by default. Security practices are always inconvenient; that doesn’t mean we can just do away with them.
UPDATE (7 Nov 2012 13:57): Luke responded to me on Twitter that the larger concern is security cameras capturing passwords. Good point. Both cameras and people you may not notice are the problem. All the more reason to not leave it showing by default.
He later mentioned someone at Sprint saying they did this who claims “No security issues.” The problem is: 1) just how do you measure that this caused no security issues? Even just for Sprint itself, that seems a tall order to verify. But it can’t address the other problem I mentioned, which is that 2) people often use the same logins across apps/sites. So if someone captured the login/password combo thanks to Sprint’s unmasked form and they later used it across other popular sites, they could gain access to the individual’s information and Sprint would never be able to track it was their form’s fault. To claim “no security issues” is, it would seem, completely impossible to verify and so shouldn’t be claimed.
Again, the better option is to provide a way to show the password, but don’t show it by default. This makes the user think about what they are doing, and they’ll be more likely to ensure nobody is peeking if they explicitly show their password. On the other hand, they could very well be looking at the keyboard and type their whole password before noticing it is being broadcast to the world around them. Indeed, when people know that each character shows briefly, they could be more inclined to try to type their password quickly, increasing the likelihood of this problem. I’m rapidly thinking this should be classified as an antipattern, hopefully before it becomes a pattern.