A Gentle Rant About the Usability of User Accounts

Recently I was involved in a massive migration project involving IdentityServer and OIDC. But that’s a story for another time. This post comes from the other side of the tracks, from the point of view of a mild-mannered user trying to create and manage their user account on your site.

As software people, one of our main goals should be to delight our users. Unfortunately, as a user myself, I am often underwhelmed, frustrated, and decidedly un-delighted when faced with managing my user account.

Email address validation

Let’s start with email. The email address is often one of the first bits of information we have to plug into an account creation onboarding screen. This is where the trouble starts.

Allow ‘+’ addresses

To help combat phishing, many folks like to use ‘+’ aliasing in their email addresses. Let’s say my email address is [email protected] . On your site I provide my email address as [email protected] , and on another site I provide my email address as [email protected] . I receive the emails in the same inbox, but I have more confidence that emails from [email protected] really came from your site. If/when your site is breached in the future and my email address is exposed, I simply change my email to another alias and set up a rule to automatically delete emails sent to the previous alias.

If your email address validation blocks emails containing a ‘+’, then this doesn’t work.

Email addresses aren’t that simple

The problem is that many developers seem to think that email validation is as simple as a quick regex like /\w+@\w+\.[a-z]{3}/. But that breaks down really fast for a lot of emails.

Remember, I’m probably trying to create an account on your site in order to make you some money, but you’re telling me that my valid email address is actually invalid. Goodbye money.

Keep it consistent

At times it’s apparent that different email address validation is used across different sections of the app. For example, the login page allows my ‘+’ address but the Settings page doesn’t.

In the spirit of DRY and not driving people batty, it’s definitely a good idea to centralize your email address validation logic. Consider using an OSS library or even an API.

What’s in a username

Another source of user account irritation surrounds the username. Usernames must be changeable, and preferably to something that is not an email address.

We are aware of the dangers of credential stuffing, where attackers attempt to login to an account using a password obtained in an unrelated breach. But the password is usually only one part of the login credentials. The other part is the the username, which unfortunately, is often an email address, and typically reused across multiple sites.

If your service has been breached, don’t just reset everyone’s password and claim victory — also allow changing the username. Don’t just change the lock, move the door to another building.

Email address as username

Email address as username? It’s really not ideal. Due to the aforementioned email address credential stuffing vector, attackers now know which email address they need to target in their attack.

It’s better to allow the user to choose a username unrelated to their email address. Ease-of-onboarding, followup, and account-verification requirements may force you to grab the email address upon account creation, but at least allow setting a non-email-based username in the account settings.

I believe this should also apply to the account for email addresses themselves. My guess is that [email protected] can never access his account because it’s always locked out. If he could disable [email protected] as a username and choose one like finallyreadloveletterfrom2010, he would be a happier camper (at least until he read that love note he lost access too. Poor Bob.)

Email addresses must be changeable

Email addresses get burnt all the time. They aren’t fingerprints or DNA. They must be changeable, easily, without calling Support, especially when the user still has access to the old email as well as other forms of multi-factor authentication. Forcing users to stay with old emails in known breaches puts your users at risk.

Again, they shouldn’t have to call Support to do this. If a user is changing their email on your site, they just might be changing it on 200 other sites as well. Talking to support for each of those adds up to a whopping waste of time and lots of negative energy toward your brand.

Change all instances of an email address

Companies tend to farm out billing and newsletter management to third-party companies so they don’t have to deal with the extra complexity and Compliance issues. Unfortunately… this leads to problems when changing contact details like the good old email address.

For example, I change my email address from [email protected] to [email protected] on widgets.com. Unfortunately I continue to receive emails at [email protected] from Stripe, Mailchimp, etc. With newsletters, I can usually unsubscribe, then resubscribe using my new email address, but it’s still a hassle. And sometimes there is no way to update the email address with a third-party payment provider because I don’t have access to that information — it’s a third party after all.

Be nice to your users. If you integrate with third-party providers of any kind, make sure that updating their email address on your site updates the email address on all the third-party services as well, ideally without calling Support.

Friendly password validation

Another big source of account anxiety is the password.

How long again?

Be upfront with the maximum allowable length of a password, especially when your password lengths are ridiculously short, like 16 or 20 characters.

It’s so annoying when a site says “passwords must be at least 8 characters”, then proceeds to reject a 22 character password. At least change the length tooltip to “passwords must be 8-20 characters long”

Allow pasting passwords

Please allow users to paste in passwords from their clipboard. I have no idea where the strange requirement to block copy/paste came from, but it smacks of developer “gold plating.” Someone thought, “Hey, you know what will make our site super secure?…Look ma, no copy/paste!” Then other Devs saw the behavior while using Big Site XYZ, assumed it was some kind of “Best Practice” in the Security Industry, and emulated the terrible behavior in their own site. It’s a working hypothesis anyway. :-)

Fortunately, more organizations are seeing the light and lifting the pasting embargo.

Which special characters again?

Site: Your password must contain letters, numbers, and at least one special character.

Me: Hmmmm, which special character? Let me try ^

Site: Nope, this password contains illegal characters.

Me: Harumph! How about "

Site: No sir. Too special for us. We only permit “special” characters.

Me: Grimaces. Let’s try a ;

Site: Buzzer! Wrong!

Me: Throws site in garbage

If you have strict character requirements, consider being more upfront, from the get-go, about which characters you require, e.g. “Your password must be 8-30 characters and contain a mixture of letters, numbers, and at least one of the characters #%@.”

My second hair-raising question is, why does you site prevent characters like quotes? It is because you’re not properly sanitizing inputs? Could my humble password end up breaching your site in a SQL injection attack? That would be a sad day indeed.

Multi-factor FTW!

First off, allow users to enable multi-factor authentication (MFA), and depending on the risk involved, consider enforcing it.

Don’t roll your own auth app

Companies should cultivate a user-centric rather than a company-centric mindset. If they did, they would not force their users to install their custom authentication app. If every company did this, I would have hundreds of auth apps on my device. This is silly. Just use an open standard like TOTP and allow users to use the implementing app of their choosing.

Question the use of security questions

Security questions can enhance account security, but they have a few issues.

If your users use real answers, what happens when that information is compromised? These questions tend to be the same (street you grew up on, childhood friend, etc) across sites, so leaked security questions could be harvested for credential stuffing as well as phishing attacks.

Some sites allow security questions as a password reset mechanism. So the only thing standing between an attacker and the keys to my account is the street I grew up on?

Truly support hardware security keys

Some sites allow hardware security keys as a second factor, but then force you to enable SMS as an alternate factor “for your security”.

Wait a minute… My account security is only as strong as the weakest component. What is the point in adding a strong second factor if I’m forced to add a weak form as an alternate? It’s like building a castle with a thick wall, but pressing the doorbell retracts the walls and replaces them with security guards.

“For your security” actually means, “for the sanity of our Support department.” They’re (rightfully) worried about people locking themselves out of their account.

Don’t force hardware keys to be a single factor

Some companies have the noble dream of ridding the world of passwords, so they view hardware keys as a single factor for authentication, much like the physical key you use to open the front door of your home.

However, until we have the technology to read minds and recover human memories, the best form of authentication remains something you have PLUS something you know. So at least provide the option to require an alphanumeric PIN in addition to the presence of a hardware key.

Allow for easy account deletion

As great as your service is, sometimes some people just won’t need it anymore. Allow them to delete it. Keeping their PII around is a liability for you and especially for them.

Before I create an account on a site I’ll often Google how to delete an account on that site first (and even how to change email, username, etc). Why? The more accounts I have to manage, the more my future self has his time leached away by past me’s hasty decisions. If I can’t delete an account, I’ll often pass.

Think of the users

In conclusion, try to do what’s in the best interests of the people that have to interface with your system. Delight them, make them glad to have an account with you.