Us product people have to walk the fine line between the two.
The following is from Tapestry Journal an app I use to keep in touch with my daughter’s pre-school nursery.
We’ve all seen this and experience that feeling of dread knowing this isn’t going to be easy. You can see hundreds of examples of bad password requirements over at Password Shaming
I tweeted the above image and Tapestry got back to me saying the app meets security recommendations, it even requires a PIN as well as password. I have no doubt this is secure but is it usable, of course not and that’s the problem.
Ease of use vs Security
Or what happens when you make passwords too difficult. Let’s look at how users cope with complex passwords.
User tactic 1: write the password down somewhere it’s easy to find
All too often, this is the result. Passwords on post-it notes or kept in an unsecured note in the Notes app.
The harder we make a password to guess the harder it is for a user to remember.
Symptoms include: high customer service costs, frequent password resets (you do measure these right?), lack of continued user engagement
User tactic 2: use the same password everywhere
Everyone does it, use the same password on every site. It may have an upper case, lowercase, number and special symbol but if it’s repeated it’s a risk.
The millions of username / emails and password combinations leaked over the years mean that many of these shared passwords are available to hackers. 81% of users getting hacked is due to stolen credentials.
You can check to see if any of your passwords have ever been leaked using HaveIBeenPwned.com.
Symptom include: users getting hacked and blaming you, annoyance that their common password can’t be used as you require 12 digits (their common password is 9).
What to do
Ensure you integrate properly with third party password managers
Don’t ever, (EVER) block the copy and paste function on password fields, this means password managers can’t work and you ironically reduce you level of security.
Using third party sign-ins
Using an OAuth2 provider like Google, LinkedIn, Twitter, Facebook or Github.
In research, I’ve seen users get confused about how the OAuth2 flows work and more often than not they are not logged into the provider meaning they have to remember a password anyway.
There are pros and cons to using this method but it can offset the secret risk and make life easier for the user.
Apple FaceID, Touch ID, Windows Hello, Android BiometricPrompt
If you have an app use the built-in security of the device. Both iOS and Android support this.
As for web apps, well W3C have agreed on a standard: WebAuth to use these OS level security features to login to websites. Browser support is patchy and Safari iOS does not support as of May 2019. You can try it here on webauthn.me to see how it works.
This is the future of authentication meaning the standoff between UX and security will hopefully be coming to end, in the meantime here’s some fantastic advice for designing password requirements: Authentication for the modern era
The psychology behind why passwords are so bad
I talk about the ways we structure knowledge in our brains and what that means for security and UX in this talk: