Evil trade-offs: Security vs. UX
By: Sergio Isidoro
Tags: Security, Technology, Software Development

“The email you chose is already registered.”

It’s a fairly innocent string you expect to see. As a web developer, this is probably one of the first strings you had to code when building your registration flows. Most developers don’t realise the impact some of these details can have on their product or service security.

This string, in an online banking service, would disclose that there might be an account associated with the email, hence violating banking secrecy. The knowledge is also an important datapoint in spear-phishing attacks — the attacker already knows you have an account; they just need to copy the email styles of the service and send a message requesting a password reset.

If your app is an on the side dating service [1], this string might disclose a cheating case to an already suspicious partner. But the consequences can go beyond bad, to life-or-death scenarios.

Some reports [2, 3] have surfaced of governments using dating apps to detect and chase down people for their sexual identity — In some countries this can lead to torture and death [4]. The message that you just saw above, as simple it may be, can destroy someone’s life.

The alternative drives people, especially developers, insane:

An error occurred. Please contact support.

This message does not tell you anything at all. Why did the error occur? Can I solve the problem myself? What did I do wrong? Do I really need to contact customer Support? Wait for a reply? Arghhh!

Hell is paved with good intentions

We all want to maximise our users’s experiences. As developers, we know first hand how frustrating it is when software does not work, gives out vague instructions or is outright cryptic. But sometimes things are cryptic by design — evil trade-offs!

Yes… this is ridiculous, but we do it for email… (source — original source unknown)

The image above was found from a reddit thread of /r/softwaregore. The only explanation I can find for that disaster is a developer trying to be helpful. On the same thread we find a very descriptive experience from u/CleanBill that helps my theory:

Reminds me of a new developer I had on my team. I asked him to make a simple username/password login screen (…) it said things like (…) “The password is correct, by a x% , please reenter”. He said he tried to make it as user friendly as possible (NOBODY EVER REQUESTED HIM THAT!).

What’s missing?

Most of us have heard about User Experience. I would go as far as saying that we’ve heard too much about user experience in the past few years. We have also learned about security — SSL/TLS, HTTPS, Man in the Middle attacks, encrypting and salting passwords. And of course, we have learned to follow technical requirements. But one thing is missing.

Requirements are not going to detail every single string a developer has to show to the user. Some of these details are thought to be trivial, or are left out due to the non technical background of the stakeholder writing the requirements. We, as developers, need to be there to cover these holes.

In the age of startups, with teams fully made up of engineers and developers, we’ve been lacking legal background of product development. Simple introductions to topics like data protection (e.g. GDPR), banking secrecy or health data protection are oblivious to most developers. We also jokingly complain about how lawyers, compliance and “corporate” get in the way of developers.

Human security (not only technical security) should also be part of an engineer’s background—paying attention to all bits of informations being given away which can help in social engineering attacks.

So, next time you’re writing a response string, pop-up warning or form message, remember: some details can cause a lot of damage.