Password Masking

Caught in the ongoing tug between ease-of-use and security is password masking, a point of contention in the past with some of my colleagues working more closely with security related issues. Whether security and usability necessarily have to be inverses of each other is something to leave for another post, but what's clear is that it's certainly the case with our current form of masking typed text strings in password fields. There are three major types of password masking I've seen.

1. Full masking: Every alphanumeric character or symbol is represented by an asterisk or dot, effectively masking them.
2. Partial masking: All characters are masked, except for the last typed key. (Example: iPhone OS)
3. Invisible: No asterisks, dots, or replacement characters of any kind will display. (Example: Unix environments)

Full Masking

Full masking is the most common technique, and while it tells you where are you in the password you've typed so far, it also gives observers that information too. With this technique, the only way an onlooker can grab those passwords is by a combination of physically watching the keys typed and educated guesses based on what the asterisks hint about the password (its length, whether slowed down typing to enter numbers or symbols, and so on). Remember, I'm talking about what can be attained visually and audibly, as that is the point of password masking. Areas like keylogging, plaintext passwords, and such are another area of concern entirely. Now, when it comes to full masking, it generally works fine until something is causing typos, which masking will hide. This includes common mistakes like leaving the caps locks key on, or missing a shift modifier key, or general typos with commonly misspelled words or lengthy randomized text strings. It's worth noting that the caps locks issue is sometimes addressed by detecting that it's on, and subsequently warning the user when it is.

To deal with this issue, it seems that sometimes entirely masked passwords come with an option to toggle the asterisks on and off, such as with the WEP/WPA key fields in OS X. In other words, it's an override option to temporarily remove masking at the discretion of the user.

Partial Masking

But what happens when full masking carries over to a device where typos are far more frequent, such as a mobile device? The user could slow down immensely, or type at regular speed and hope that the login won't lock down or throw a CAPTCHA form after a couple invalid attempts. The iPhone OS addresses this by masking all characters in dots, except for the last typed character (for a couple seconds). It's an improvement, but at the expense of anyone peering over your shoulder seeing each last character. Anyone keeping an eye the entire time can thus see your entire password in the clear, and at a readable pace considering that even the fastest typists on mobile keyboards are a huge margin from the fastest on the desktop keyboards. I have mixed feelings about this, but then again, even fully masked, typed keys on touch keyboards display their character in a tab above the area obscured by the tapping finger. So any watchful person can still catch on that way, regardless of whether the password field itself is fully or partially masked. This is evident on such touch keyboards as the ones on iPhone OS and Android.

Invisible Masking

In a UNIX environment, you'll notice that password prompts give no feedback for what you're typing or what you've already typed, ironic given that this environment is where strong complex passwords are common. I've seen this confuse many, many users, and it's a commonly asked question that won't go away. Eventually, most people get accustomed to this, and it becomes just about as easy to use as full masking - for most cases, that is. But when it comes to lengthy randomized passwords, entering passwords becomes a snail-paced task, during which keystrokes become easier to observe and follow. (This is unless you happen to be a god at rapidly typing 40-character alphanumeric, mixed-cased passwords interjected with symbols with and without modifier keys.)

The Locks at Every Gate

As we raise the number and complexity of locks on a gate, we also construct higher and higher hurdles for intruders to overcome, but also for the people who have to encounter these security measures everyday, every hour, or even every few minutes. These measures typically work fine, but serve users poorly in intense cases to the point of inducing people to find less secure workarounds ranging from writing passwords to copy-pasting a password in the clear. (Try typing a 30 character alphanumeric, mixed-case Wi-Fi WPA2 key on a mobile physical or touch keyboard, and see if you aren't tempted to copy-paste too.) The less visual and acoustic cues there are, the more it slows everything down. You'll get used to it, but we just need to vary where to draw the line on a use-case basis because ultimately the most inconvenienced person is not the sinister characters - it is you.

Blast from the Past: SDI and MDI

This is an entry I wrote on March 20, 2006 touching upon SDI and MDI:

Warning: This is a usability and interface topic. You may quietly exit through the back doors. No hard feelings. Otherwise...

I know that Adobe Acrobat 7 has been out for quite a while now, but I figure that I need to get the word out wherever I can. The following is a problem that's been bothering me since Acrobat 6.

Notice this. Earlier versions of Adobe Acrobat used a multiple document interface (MDI), where all documents resided within a single parent window. The problem was that they forgot to add "tabs" for easy navigation between the documents in this multiple document interface.

I wrote a complaint in the official forums a while back, and in version 7, it seems that they finally tried to solve the problem by switching to a single document interface (SDI), where each document has its own window on the Windows Taskbar. But the Adobe Acrobat team forgot something again. If you exit any given document with the Microsoft Windows [X] button (the red one in Windows XP), every single document closes. The expected behavior, based on other applications written for Windows, is that only that one document should close (not all of them).

Or perhaps the Acrobat team has a good explanation for this behavior? (I certainly can't think of one.)

My original entry: http://gordeonbleu.livejournal.com/20578.html