Security Must Focus on User Experience To Be Effective

We need to focus on better user experience in the security industry. People are reluctant to embrace any kind of change, because they are used to the current systems and processes, even if they are not working. When we combine security changes with terrible user design and experience, it leads to people fighting against recommended security practices, or finding ways around the controls to minimize personal pain and annoyance. Too many people have been jaded by bad experiences with security rollouts and changes in the past and are reluctant to take one new security recommendations even when they are done better or by different teams than the failed ones before.

This can be in the form of previous corporate experiences where security changes caused a lot of issues or headaches or personal experience. Let us use passwords as a perfect example. When users have faced terrible password practices in their personal lives, it makes it really difficult to have corprorate users adopt good password hygiene and use things like multi-factor authentication (MFA), password vaults and managers, and occasional password rotation.

As I struggle to migrate away from LastPass after their most recent breach, I have run into a myriad of issues with the websites I had added to my LastPass account in rotating their passwords. These issues are basic and frustrating. Even more so, it makes me afraid as a security professional. If these companies cannot implement good experience for their customers, imagine how terrible their internal security experience must be. And these are major enterprises such as financial institutions, insurance carriers, medical providers, telecoms, etc. Here are some of the terrible user experience practices I have come across thus far:

1. Passwords not allowed to be pasted. This breaks password managers, which means you are asking people to type in complex long passwords by hand. And in most cases you have to type the new complex password twice, and then enter the old password, all by hand. What does that do? It prevents people from actually setting long and complex passwords, as it is really annoying and time consuming, and it prevents people from changing their passwords as it is so difficult. Isn’t that the opposite of good password security?
2. Not telling users what characters are allowed in passwords. Users generate a password, and the system fails and then tells them to exclude certain characters. Which again, breaks the password managers that may have now updated with invalid password generated. Why not tell users all of the information that they need about the rules behind the scenes before forcing the users to fail?
3. Not telling users the limit of how many characters a password can be. Similar to above, this leads to users pasting a long complex password from password manager that is longer, which fails. And now they have to start over again. No sense in hiding this information from users and waiting for failure.
4. Not allowing users to change their usernames, only passwords. Maybe you want to change your username and your password because that account has been in a breach and you want to add extra security. Or maybe you just want to change it for the sake of it. I do not see a good reason why this should be prevented, other than it takes a little extra effort to code. Not a big loss or annoyance, but still a pointless limitation.
5. Not allowing all possible characters and long passwords. This is not the 90s. Your back-end systems should be able to handle all possible characters from the main keyboard and not limit passwords to 12 characters total, or 15, or 20. This is ridiculous and insecure. There are too many enterprise vendors that do not even permit the use of special characters by their users, or limit those to only 1 or 2 special characters. We know how good password cracking technology is these days and restricting users from making their password more secure is the opposite of good security practice.
6. Do away with security challenge questions. Security questions are annoying and there are only so many different ones possible across different sites, so people end up reusing the same questions and answers. As a result, if one site gets compromised hackers can use your security questions to reset passwords against many other ones. The only way around that is to create random questions and/or answers to security challenge questions, but then it means users cannot remember them themselves. Which means, users end up saving these in password managers or similar, which defeats the whole purpose. Why not simply enable MFA and be done with it?
7. Terrible MFA/2FA implementations. Multi-factor authentication (and its poor counterpart two-factor authentication) is the best protection mechanism we have to protect passwords, but so many companies utterly fail at good user experience or implementing MFA that again jades the end-users so much that they are reluctant to use MFA when it is well designed and implemented. Here are some examples of poor MFA practices I have seen:

• SMS only. We know this is the easiest way to bypass MFA/2FA and SIM-swapping is a thing.
• MFA enabled, but it is a checkbox a user has to select upon login to use. This is the one that makes me laugh and cry so hard. This big enterprise vendor allows me to use MFA to login, but I have to click a checkbox first to use. So, in reality, it makes me feel a little better, but does absolutely nothing as it makes MFA optional. Why does this enterprise think that a hacker would want to check the MFA checkbox when trying to gain access to my account? This MFA implementation is just for show.
• No ability to manage allowed or remembered devices. Some enterprises only prompt MFA or security challenge questions when a login from a new device is detected, but do not allow users to select whether to remember those devices, and automatically add them to the remembered device list with no ability to show users what all those devices are. So, you could lose or forget you ever connected to this sensitive vendor account from a device and then get rid of it, but the vendor will still think it should be remembered when you no longer have it. Not a good security practice.
• Forcing users into using a specific MFA application. This one just makes me mad. Why not allow users to register for MFA using an authenticator of their choice? Now you are forcing people to use multiple authenticators and try to remember which one goes with which logon. Some of these authenticators are so terrible that they do not even allow custom naming convention to tell users which MFA code b refers to which account/website…

What are some of your experiences with poor user practices or poor security implementations that jade people from adopting good security practices in the future?