As I’ve noted a number of times previously, the fact that we still have accounts “secured” by passwords this far into the 21st century is pretty much a security abomination. Adding on multiple-factor security tokens and such is a big help, but passwords themselves remain a weak link in the chain of security, and a vast number of sites and apps rely on passwords without any additional authentication measures at all.
Since the dawn of online systems, it has been standard practice to obscure the display of entered passwords by one means or another.
There are basically two reasons for this. One is the obvious issue of someone looking over your shoulder while you’re logging in.
The other is steeped in computing history.
Early online systems were primarily accessed with paper printing terminals (e.g. Teletype Model 33, IBM 2741, etc.), and leaving around or carelessly disposing of a printout with your password visible could be a serious mistake.
The earliest printing terminal systems were often “half-duplex” in design, meaning that typed characters were echoed locally. To obscure passwords in this instance, the common technique was for the system to overprint a bunch of characters a number of times before the user entered their password over the resulting black blob of ink. This wasn’t foolproof, but was remarkably effective at the time.
For printers on full-duplex circuits, it was possible simply to suppress any echoing of the user password at all, or to print a character like asterisk in place of each typed character.
This same basic model continues today on the Web and in app ecosystems.
Entered passwords either aren’t echoed, or commonly are replaced with asterisks. Some app systems will give you a brief glimpse of the input character before replacing it with an asterisk.
Unfortunately, these kinds of techniques have become decreasingly useful as users have been encouraged or required to use ever longer, ever more complex passwords and passphrases, because the probability of mistyping these entries increases with their complexity.
And it isn’t just a matter of having problems logging in.
The same obscuration techniques are often employed when setting or changing passwords, typically combined with the ever-popular “enter it again” prompt or field, based on the flawed theory that you’d never type the same obscured input in error twice and so set your password incorrectly (and locking yourself out) as a result.
For that matter, even typing the same complex password twice in a row in an obscured field to set the password correctly can be an exercise in frustration.
Recently, the trend toward obscuring input fields has been spreading to all manner of other entries as well, including check account data, credit card numbers, even dates of birth — and much more. I’ve seen forms where even the fields for inputting your first and last names were obscured with asterisks!
Such obfuscations wouldn’t be such a significant problem if there existed a routine way for the user to disable them on demand.
It’s stupid — bordering on insane — to force users to jump through the hoops of blindly entering complicated passwords or other data when they’re alone and there’s no risk of anyone surreptitiously peering at their screen.
And for users with poor typing abilities, motor skill or visual limitations, or other related issues, these input methodologies can be downright abusive. This is one of the most common complaints showing up in my inbox about interface issues.
But wait, it gets even worse!
Many user interface designers, laboring under a twisted misconception of security, purposely make it even more difficult for users to enter their passwords, by rigging their pages or apps to prevent copy/pasting of passwords, and/or by blocking the use of password managers, field autofill systems, and so on.
This really isn’t rocket science.
Except in crucial enterprise environments or especially elevated security situations, it should be common practice for user interfaces to provide a method for the user to see their passwords or other data as they enter it if they choose to do so — a simple enabling checkbox with an appropriate warning would suffice. And this would be the display of the entire password or other input, not just a flash of each letter as it’s being typed.
Some systems already provide this to one degree or another, but this is relatively unusual to find.
Android for example has a little “eye” symbol next to where you enter Wi-Fi passwords, that can be clicked to display the password. This is good, though I’ve had many users tell me that they had no idea of what that symbol meant and so didn’t realize that they could view their Wi-Fi passwords in that manner.
But again, this is an exception to the more general situation of user interfaces across the Web and app worlds that don’t provide such options.
We should be striving to completely eliminate passwords from our systems, replacing them with more robust authentication and security models.
For now though, we still must live with passwords in most cases, and the option should be routinely provided for users to display entered passwords or other obscured data when they choose to do so.
And as for those user interface designers who purposely and unnecessarily block tools and techniques that would make it simpler for users to enter complex passwords — well, since this is a family-friendly blog I won’t mention here what I feel should really happen to them!
Be seeing you.
–Lauren–
I have consulted to Google, but I am not currently doing so — my opinions expressed here are mine alone.
– – –
The correct term is “Internet” NOT “internet” — please don’t fall into the trap of using the latter. It’s just plain wrong!