The Balance Between UX and Security
In my last post, I briefly talked about my initial experience of working as a designer in a security startup. I promised a follow-up post eventually—and here it is.
We, of course, want to advocate for users to have a stronger password than just “password.” However, let’s consider Macy’s customers: would you expect everyone in this group to know what the word “alphanumeric” means (I admit I had to look it up the first time)?
Now, let’s put that in contrast to MailChimp’s sign up page:
This phrase is app security jargon. In fact, I didn’t know this is considered a vulnerability until I joined the team. Basically, it means you can get an application to tell you if an email address is registered with the application. This is done by intentionally entering the wrong password on log in or by submitting the address to a form that checks whether it exists in the app’s database. This is a technique that could lead to a combination of different exploits, from social engineering to network interception. Even if not, one could at least find out whether or not a particular email is associated with a database…. Think about how others could find out you’re registered to a site that you don’t want them to know about. *wink wink*
As seen here, we can test whether or not firstname.lastname@example.org is registered to Instagram by intentionally testing another email that’s unlikely to exist. Sorry, Riandi, false alarm; please ignore that email:
An alternative solution would be to always respond with the same “Email is sent” message even when the account doesn’t exist. However, this can prove a little problematic if the user owns multiple addresses and cannot recall which one was used for registering to this particular app. The trade-off is more debatable here, and ultimately, our decision should depend on the specifics of the app. For a general purpose site that has other protections in place, it might not be as necessary to worry about this risk. However, if the site involves sensitive personal info of any kind, it wouldn’t hurt to include an extra lock on the door.
If we were to take the safer route, I would recommend adding another line to our message to clarify our intentions, along the lines of “If you don’t see an email in your inbox, you might have used a different email to register.”
Even before I acquired infosec paranoia, I already knew that sending unencrypted sensitive data via email isn’t a good idea, which is the exact reason why I cringe every time I receive a password recovery email like these:
The idea behind the “Click this link to change your password” method is to reduce the exploitation surface. If an attacker intercepts an insecure connection, then transmitting the email via plain text will be a risk factor, whereas sending a reset password session link will prevent such an issue to a certain degree. While sending the password directly means that the user doesn’t have to go through the hassle of setting up a new password, the downside is much more significant.
On top of this, we have the option of multi-factor verification to provide another layer of safety, as it’s less likely that an attacker would have access to multiple factors at once. As this research shows, multi-factor verification is considered quite user-friendly if implemented correctly. The important thing to remember is to allow users to choose whether or not they want to utilize it. If they do, also give them the option to decide whether or not a device can be trusted, so that they do not have to repeat the process every time they sign on. Lastly, give them a way to get into the system if they don’t have access to a verification device, either through a set of recovery codes or a backup email.
Now, we are getting to the nitty-gritty stuff.
As I wrote above, I used to think that perceived reliability is more important than actual reliability (working on the surface but broken underneath). The reason I said this will make things fall apart in the long term is because it only takes some basic knowledge of web technology to crack the system. Take the password strength requirement above, for example. Even if the implementation is easy to use and functional, if the protection is only dependent on client-side scripts, then in a hacker’s eyes, it’s just a decoration.
This section deserves a post on its own considering how quickly the topic of web hacking can become complicated. The rule of thumb is that, if there is a way to tamper with your application’s code, then it will be tampered with sooner rather than later.
If the developers in your team don’t try to build things securely, we are here to help.
All of this goes back to the central concept of balance: the stronger the security being employed, the more consideration has to be given to ensure it won’t impact the experience, and vice versa.
In essence, offering a good UX really means keeping your users happy when they use the application, and the reason to have a solid foundation of security is simply to maintain that level of satisfaction in the long term.