Passwords Are a Design Problem

Illustration of a Password Entry Field

Like a lot of urgent advice, this terrific article about best practices in creating strong passwords, written by Jon Xavier of Fleetsmith, feels both necessary and tragic. Necessary because, as the article says, there is “so much outdated, misleading, and just plain wrong information” about how to create and maintain passwords out there. And tragic because this most basic of security measures, which few of us have ever really mastered, seems likely to continue to challenge most users of digital products for the foreseeable future. It’s well worth reading the article in full, but a quick rundown of its main takeaways is also worthwhile:

  • Passwords should be a minimum of ten characters long, and ideally as long as possible
  • Neither special characters nor numbers are necessary in order to make passwords stronger
  • Cleverly swapping numbers for letters in your passwords is completely ineffective
  • A password should only be changed when there’s reason to believe it’s been compromised
  • The same password should never be used on multiple sites
  • Two-factor authorization should always be turned on if it’s available
  • Never give honest answers to password security questions, e.g., What’s your mother’s maiden name?

Xavier goes deep into the myths driving password implementations and usage today, but one thing he doesn’t touch on is how poor is the user experience of passwords across platforms and products. Create six different accounts at six different web sites and you’ll very likely encounter six different approaches to encouraging and enforcing password strength and security, some egregiously lax and others excessively restrictive.

That inconsistency alone undermines much of the vigilance that otherwise responsible users might bring to password creation. If you’re presented with a new set of rules to comply with each time you undertake the same essentially diversionary task (no one sets up a password as an end in itself; they only do so as a means towards achieving some other goal), your devotion to security will inevitably be worn down to a lowest common denominator approach.

Perhaps the most important advice that Xavier offers is:

The most important factor in password safety is how they’re stored.

If you’ve used password managers like 1Password, my personal favorite, you’ll likely nod your head in agreement here. Not only do password managers markedly improve password safety, but they also ameliorate the experience of using them to begin with. Once you’re up and running with 1Password or similar apps, your online activity feels inherently more secure.

Still, huge gaps remain. For example, when generating a new password, these utilities can only guess at the security requirements of a given site or app. So if the constraint mandated by the site is, say, twelve characters including at least one number, and the password manager happens to be set to generate strings of random words that are thirty-two characters or longer, it’s up to the user to mediate the disparity.

It’s also difficult for a password manager to understand when a password is applicable to more than one site or app. Once a password is created, it’s often matched exclusively to the domain of that site. So if your login is also valid on a closely related site, as is the case with many sites from large companies, the password manager won’t automatically recognize the relationship and present the relevant login.

What’s more, grasping the added complexity of a third-party piece of software can be a challenge to many new users. To use one of these utilities effectively, you have to adopt it as a habit, which can take time. That can result in an intermediary phase where some passwords are stored in the manager and others are stored elsewhere using other means, confusing novice users even more.

Of course you could use the password utilities now built into many operating systems or browsers, which lately have been improved significantly. But if you go this route then you’re sort of stuck there, because accessing those passwords across the wide chasm between products or platforms is high friction at best.

On the desktop, while it’s easy enough to generate and access passwords in a browser, doing the same for native apps, much less the operating system’s own password prompts, is less straightforward. Manual copy and pasting is often the only way to bridge that divide. And this is especially true on iOS and iPadOS. While password access has improved greatly over the years on mobile, the landscape is still pretty unpredictable. Generate a new password in one app, and you may or may not be able to access it easily on the corresponding web site.

And none of this takes into account the excessive frequency with which all kinds of products and platforms prompt users to type their passwords, often without making it completely evident why password entry might be necessary at a given moment.

Compare the experience of passwords with the experience of, say, accessing your email, using a web browser, or performing any kind of search. Regardless of your host or client or even platform, these conform to more or less the same patterns of experience. That’s because like passwords, they’re decentralized pieces of technological infrastructure, but unlike passwords they’ve benefitted from an accretion of best practices that over time have have evolved into more or less universal standards. By contrast passwords still seem immature, developmentally arrested by efficacy myths, and suffering from continual UX neglect. Passwords are clearly a user experience problem starving for design attention.

+