Corvus Consulting

In this third of four posts about passwords as a technology, I’ll examine some of the ways that password interfaces are changing, with the goal of describing a new checklist for designing security into applications. Other parts of the series are linked from Part 1.

Designing an interface for password-based authentication used to be a fairly simple affair. A couple of fields, a button or two, and maybe a nice touch to prevent the embarrassment of accidental caps-locking. And, of course, a big flashing Access Denied message. Well, maybe not, unless you’re designing for Hollywood. I love those flashing screens. Hollywood aside, the typical password interface is something that we expect to look like this:

These interfaces were designed for tymes of yore, when networks were islands inhabited by few people, and the most valuable information was still paper-bound. The classic design pattern, almost certainly among the most successful patterns, was drafted into service on the nascent web as we raced to build the connective excitement that happened after the user had been authenticated.

The combination of pressures that the web brings to the classic password model have emerged as a concern for web service providers in the past couple years. Designers are responding in the absence of a widely-adopted standard, and as such are implementing new takes on password interfaces more or less experimentally. This new diversity of password interfaces has brought out some innovative thinking, but it’s all too common that interfaces are inconsistent and obscure and less usable in their behaviour than the classic model.

A recent post on Tod Maffin’s blog and the comments that followed illustrates the problems caused when people are asked to suddenly create and recall passwords conforming to seemingly arbitrary rules. Tod described what he was asked to include in a new password:

Password: must contain at least one uppercase character. Your password must be 6 or more characters, contain at least one lowercase character, one uppercase character, one digit, and no repeated sequence of 3 or more characters. Your password can’t be a subset of your login name.

The new, sudden age of strong password requirements turns a mastered process into a contortion, where necessary changes to the interface subvert themselves. To illustrate, a Simpsons gag deftly sums it up.

Finally, it’s time to present the Good Guy Awards at the Springfield Civic Center. Inside, there is a large pinkish curtain with a smiley face with a halo. The curtains open and Krusty steps through.

…

Krusty: [laughs] Now, I’m told there’s a glitch in our Internet

web cast. So all of you out there type control-backslash-

semicolon-alt-dot-escape and you’ll be fine.

[cut to Comic Book Guy in front of an iMac, typing]

CGB: Ahh! Perfect!



What the Comic Book Guy, the EveryGeek, will do, just to watch a small, stuttering video. It’s funny to watch on the Simpsons, but painful to think that users are being asked to perform mental contortions as passwords. Rather than call out websites and applications that don’t do things as well as I think they could, I’ve been keeping non-incriminating notes on password-related frustrations I’ve encountered or read about elsewhere, and made them the basis of my wish-list for more stable and complete strong-password interfaces.

Password Courtesy

I find that many password interface designs take a cagey stance towards visitors, as if to say that if you don’t have a working password, you shouldn’t even be looking at the form. While it makes sense for a gatekeeper to give out as little as possible to unverified visitors, it also can leave the forgetful in a lurch.

Courtesy 1: Be Up-Front with Password Rules

There’s a good enough chance that seeing the rules again will jog a password back to recollection. I’ll admit that suggesting this makes me feel weird. However, when I think that the rules for making a password in a system where anyone can join, the rules in play for strong passwords aren’t exactly trade secrets when clicking ‘Join’ or ‘Sign-Up’ brings them into clear view.

In the rush to add stronger password requirements, some password creation forms aren’t updated to reflect the new reality of extra validation criteria. There’s no excuse for this one. Password entry interfaces that don’t tell you tell you up-front the requirements of your password, only to spring them on you when you try to submit the form and it fails validation, are evil.

Courtesy 2: Provide for forgetfulness

The password experience happens in both using a password, and when a password has been forgotten. Many interfaces do a good job of connecting these flows with a ‘forgot password’ interface, but they are often added as afterthoughts. Because they represent one of the most potentially stressful situations a user will confront with the software, they need to be handled with a lot of care and rooted in an understanding of how your application’s users are likely to respond to the situation. Sadly, where an email-based reset feature is not used, security questions are the norm.

Security questions, though they seem like a good idea, have caught me in a bind more than once. The questions are often so generic as to be based on easily found knowledge about me. Moreover, I fear that the answers are collected for marketing purposes, and so I usually lie on them. The problem is, I forget my red herring answers because, well, they weren’t real. My answers, even when they are honest, are often submitted sloppily and without much thought about how I may need them in the future because my focus is on the now and getting into the service. I suspect that this is the case for others.

A Gentle Touch

Though I likely won’t make friends of security proponents with this position, I’ve come to believe that strong password interfaces should encourage more than require very strong passwords, i.e. those that meet multiple criteria, like Tod’s infamous example. Here are two policy examples that show better what I’m thinking:

Policy 1: A password must use at least one of the following practices:

* No fewer than 7 characters

* Not a dictionary word or include your user name

* Include upper and lowercase letters

* Include at least two number or punctuation characters

Policy 2: A password must be at least 7 characters, and suggest the following:

* Don’t use a dictionary word or include your user name

* Include upper and lowercase letters

* Include at least two number or punctuation characters

These policies place the emphasis on getting people towards better password habits, rather than requiring them. I think that this provides a gentler user experience, and increases the likelihood that the password is memorable to the person entering it. Encouragement is a key factor in getting users to employ more than one rule for creating strong passwords. There are two interfaces that I think do this well: Google and the Keychain Application’s Password Assistant in OS-X.

Google’s interface uses some AJAXy fun to give dynamic feedback, which is great for a webpage. The interface doesn’t go to far in suggesting other measure past length, which is likely best for Google’s massively diverse user base. Not too shabby, and I don’t give Google an easy ride on interface design!

The Keychain’s Password Assistant, a desktop application, is more intensive since by nature it’s whole reason for being is keeping passwords safe. What I especially like about the Password Assistant’s approach is that it suggests improvements along the way, most noticeably by leveraging the operating system’s built-in dictionary.

An ideal interface, in my mind, would prompt the use of strong-password rules, but not require their use, and offer suitable encouragement as the Google and Apple interfaces do.

This quick pass at a mockup for such an interface emphasizes responsiveness to desired behaviour, i.e. the use of strong-password practices, and walks the user through the practices one at a time as suggestions, showing the strength of the password growing and the tips used as they are employed.

Requirements for Improved Password Experiences

* Show password requirements up-front

* Dynamically encourage strong password practices by providing relevant tips, rewarding improvement and warning against weaker passwords

* Don’t require multiple criteria to be used in a password, but recognize when it does happen (rewarding improvement)

* Provide for forgotten passwords without over-taxing memory and using invasive interrogations (privacy-based security questions)

This list is too vague to be called requirements, properly, but the goals are easy to understand, and not very hard to implement, though they do take more work than the standard interface we know very well. In the web-connected world, what we thought we knew turned out to not be good enough, and as makers of web and desktop applications we need to take people to that next level.