For most people, the experience of creating a password is almost exactly the same as it was 20 years ago. Consider for a moment just how exceptional that is, given how much technology has changed in that time. Picture a cell phone from 1995; remember its weight, antenna and tiny dark display. Now picture current smartphones, with large touchscreens, HD cameras, and cloud connectivity for infinite storage. It’s quite a different experience. And yet, coming up with and remembering compliant passwords is as difficult as it was in 1995. (Password managers, which generate random strings of characters and store them on the users’ behalf, and biometric identifiers such as TouchID are standout exceptions to an otherwise stagnant arena of user-authentication technology.)
We’ve all experienced the following three friction scenarios. By anticipating these frustrations and building our forms with them in mind, we can prevent the friction before it happens.
Show the Rules
Imagine you’re about to buy a pair of shoes from a site you haven’t shopped on before. At checkout, you have to create a password. You’re presented with a crisp, white, rectangle labeled Create a password.
You go with your old standby, hectorthecat, and tab forward, only to be slapped on the wrist with an error: “Password must include at least 1 uppercase character.” You try again:
Hectorthecat
Error slap: “Password must include at least 1 number.”
Hectorthecat1
Error slap: “Password must include at least 1 special character.”
Hectorthecat1%!
Error slap: "No spaces or % or ~ < >;"
Hectorthecat123!!!
Error slap: "Password cannot contain incremental or decremental sequence of letters or numbers." (This last message is an actual error message from mint.com.)
[Give up, close the tab, and buy the shoes somewhere else].
When a system doesn’t show the requirements beforehand, users are essentially being asked to play a game where the rulebook is hidden. That’s neither fun, nor fair.
The Solution: State the password requirements, and make sure that the user can see them the entire time that the field is selected. If you can successfully reduce some of the technical restrictions, you’ll have less text to display and fewer rules for the user to process, making password creation faster.
It’s not enough to just have a link to password requirements (most people won’t notice it or won’t bother expanding that link); password requirements should be visible at the time when the user is creating the password. (And in case you were considering putting the password requirements inside the label itself, don’t. Placeholders in form fields are bad for many reasons.)
Show the Input
With complex requirements, users make up a compliant password on the fly, adding characters and symbols until it’s valid. And at that point, it’s not so much the user’s password, as it is a random string that fits this system. Making matters worse, that string is hidden from the users as they invent it, because most passwords are masked. If they want to remember what they ended up with, people will have to carry that information in their short-term memory, as they create it, thus increasing their cognitive load.
Another downside to masked inputs is that they cover up typos, which the user may not have detected. This is particularly important given that many users create passwords from their mobile devices and tablets. Not surprisingly, research shows that users have more errors when typing in passwords on smaller devices than on desktop computers (Von Zezschwitz, 2014).
The Solution: Allow users to unmask the password. Seeing the password will support memory and will allow users to check their work. On desktop, hide the password by default, and next to it, place a checkbox labeled Show password. On mobile devices and tablets, show the password by default and let users toggle the visibility with a Hide password control. You can be more permissive on mobile because it’s easier for users to shield their device from shoulder-surfers. People are also less likely to be creating accounts for their most secure services while on a phone.
Show the Strength Meters
Detailed password-composition requirements force users to jump through what feels like arbitrary hoops. People comply because the site forces them, but they end up creating easily guessable phrases. Satisfying the requirements does not necessarily result in secure passwords when real humans are making them up just to get past the registration screen.
The Solution: Motivate people to create better passwords by showing how secure the password is.
A study by Egelman et al. (2013) found that strength meters motivated users to create stronger passwords. Visually representing the strength of the user’s password, and showing that there is room for improvement, changes the motivation. The benefit is getting a secure password, instead of just complying with a system’s arbitrary command. It’s a slight mental shift that has a potentially large impact on security. (Moreover, reaching the full green bar adds a modicum of satisfaction in an otherwise joyless task: a nice example of gamification used for good.) In general, focusing on the benefits is an effective way of persuading users to use your products or services, and it’s one of the top recommendations in writing for the web.
Note that indicating progress toward compliance isn’t the same as a strength meter. Apple.com and healthcare.gov show you how many hoops you’ve jumped through and which ones are left. A slight copy change could nudge users into feeling more motivated, less bogged down, as they type.
Conclusion
The three recommendations presented here ease the process of creating a password, and they all fall on the side of user experience and interface design. They can be addressed without major technical investment and overhaul. But additionally, I urge usability advocates within organizations to make a case to simplify password requirements. Usability professionals typically receive strict security requirements from a separate department. It’s generally accepted that nothing can be done about them. But that’s not the case. (Note that this conflict between usability and security has also been around for decades.)
- For the IT and security teams, point to research that shows that standard guidelines for complex passwords are more vulnerable than other types. For example, a study from researchers at Carnegie Mellon University recently showed that “certain combinations of requirements [for longer passwords] were both stronger and more usable than the traditional complex policy” (Shay et al., 2014). And reiterate how users who do create complex passwords, often store them in unsafe places (on post-its, in a drawer, under the keyboard, or in a file on their computer), therefore making them easy to find.
- For the product and sales teams, articulate how users are easily scared off by login walls and complex demands from the system, which results in lower conversions. When account creation is mission critical, the signup process needs to be as simple as possible.
By making a technical case for simplifying requirements, and a business case for a more satisfying user experience, you will be more likely to enable your users to quickly and easily create secure and compliant passwords.
References:
- Egelman, S., Sotirakopoulos, A., Muslukhov, I., Beznosov, K., & Herley. C. (2013). Does my password go up to eleven? The impact of password meters on password selection. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '13). ACM, New York, NY, USA, 2379-2388.
- Komanduri, S., Shay, R., Kelley, P.G., Mazurek, M.L., Bauer, L., Christin, N., … Egelman, S. (2011). Of passwords and people: Measuring the effect of password-composition policies. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '11). ACM, New York, NY, USA, 2595-2604. (Warning: link leads to a PDF file.)
- Shay, R., Komanduri, S., Durity, A.L., (Seyoung) Huh, P., Mazurek, M.L., Segreti, S.M., … Cranor, L.F. (2014). Can long passwords be secure and usable?. In Proceedings of the 32nd Annual ACM Conference on Human Factors in Computing Systems (CHI '14). ACM, New York, NY, USA, 2927-2936. (Warning: link leads to a PDF file.)
- Von Zezschwitz, E., De Luca, A., & Hussmann, H. (2014). Honey, I shrunk the keys: Influences of mobile devices on password composition and authentication performance. In Proceedings of the 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foundational (NordiCHI '14). ACM, New York, NY, USA, 461-470. (Warning: link leads to a PDF file.)
