Blog: How Tos
Security vs User Journey
Something I often think about is how my recommendations for clients to fix small security issues can spoil / complicate their users’ journey.
I understand that UX is hugely important, even subtle changes can influence whether a journey is completed or abandoned. The difference between getting a sign-up or sale can be nuanced- and costly if not done properly.
It’s safe to say that UX security flow is a real burden for developers. The smoothest user journey would never be hampered by things like passwords or 2FA / MFA.
…and that’s the challenge.
A perfect example is username validation, the method of finding valid usernames or email addresses on a web application.
It’s also a vector that attackers use, brute forcing an API to get user information. A recent example is Facebook, where every phone number was requested via the API and information was collected when it was returned.
There are many different methods to validate usernames, the most common is forgotten password functionality.
Forgot your password?
This one seems simple but the effects when handled differently are profound. When you request a password reset the API checks to see if the address is actually listed. If the address is listed it’ll go straight through to the “we’ve sent you an email” page. If the address isn’t there it’ll give you a “nope, nothing to see here” type of response
It’s the difference between those responses that can make it possible to enumerate usernames.
It’s common in many applications, a good example is Spotify. When I request an email that isn’t in the system, I get this response:
Compared to when an email address is in the system, a different message is returned and the information of a valid email address is found:
So, what is the risk here? Well, if a list of valid usernames is obtained, they can be cross-referenced with security breaches or leaked passwords and the accounts can be hijacked.
An attacker can even use a password list to try and gain access to the account by guessing lots of passwords, but hopefully there would be a lockout policy to prevent this.
Email address not found
If I’m trying to access a website I had an account on ~10 years ago, I may have used a different email address, so being told that the address doesn’t exist is very useful, I can try other emails I’ve had until I find the right one. Otherwise, I might be waiting endlessly for a password reset email that never arrives.
Which answer is right in this instance, security or user journey? It’s a tough one that depends a lot on the risk appetite of the company, the data stored within the application and often the number of competitors. There is no easy answer to this one.
Security IN the user journey
Rather than focusing on username validation it’s worth looking at different measures to prevent functionality being abused.
Spotify use a reCAPTCHA so that an automatic scraping of email addresses can’t be undertaken, it’s unlikely someone will manually enter email addresses and fill in a reCAPTCHA each time, it just isn’t an efficient use of an attacker’s time so it’s an effective barrier:
Different methods are available too, such as using a two-factor authenticator token, or in Facebook’s case asking you to identify a certain number of friends before sending the reset.
The risk is still there, but it is vastly reduced. The customer doesn’t have any control over these measures though, and if their appetite for risk is low this may not be acceptable.
What’s to be done?
There are steps that users can take to ensure small risks like this don’t affect them, it all comes back to the classics:
- Use a strong unique password for each service
- Configure two-factor authentication on all services
These two steps would reduce the risk of username validation to almost zero. By using a strong unique password for each service, even if a service is breached that password cannot be reused on other websites.
A brute force password-guessing attack would also fail as each of the passwords is strong with at least 12 characters, including a mixture of capital letters, numbers and symbols as well as lower case letters.
Configuring two-factor authentication adds an additional barrier to access, even if a password is reused or brute forced, the attacker will be prompted with a two-factor authentication request.
2FA codes are sent via SMS or created by an app on the users’ phone. An attacker would have to put in a LOT of effort to get that phone, which just isn’t viable for them.
The Security vs User Journey debate isn’t going away any time soon.
It’s a constant issue in journey mapping, to encourage people to use a service without putting hurdles in the way. Careful thought needs to be taken at the inception of the design stage to make sure this balance is struck at the right level. Users should be aware of this balance and take additional steps to protect themselves online.