Security is a difficult topic. We hear about big data breaches multiple times a year and the frequency, as well as the size of the breaches, seems to grow. The latest data breach, called “Collection #1” resulted in over a billion published email/password combinations. But the breaches itself are only one side of the equation. Especially in the case of these breaches were login data is leaked the real danger lies in the habit of many users to reuse passwords. This shows security is not only a technical topic, but the users and their behavior also needs to be taken into account as well. More often than not this is not the case. In this post, I will show you some bad, but widespread patterns on how not to bake security into your products. But also some principles on how to do it better.
If you build security features in a way that users circumvent them for the sake of convenience — you are building them wrong. It’s your fault not the user’s.
It doesn’t matter if you are building a bank or a chat app — security is always important. It’s only the immediate impact of a breach that might vary. The consequences of bad security patterns go beyond your product and influence the safety of the whole internet ecosystem. It’s the responsibility of everyone that is involved in the development of software-based products to make sure that their products are secure. This means security is not a topic for developers only. Product managers and designers are responsible as well. In fact, the role of the latter group in this field is often underestimated. Security for many is just something that “has to be there” and then the product is designed around it. All this in hopes to reduce the impact this nasty thing might have on our precious conversion rate, revenue or engagement. But we have to acknowledge and anticipate that security is part of the user experience and that we should build our products in a way to promote user behavior that limits the risk of incidents and their effect. If you build security features in a way that users circumvent them for the sake of convenience — you are building them wrong. It’s your fault, not the users’.
Security is part of the user experience
User experience, or short UX, does not just equal convenience and conversion rate is not the single most important metric there is. In fact, UX as one of the buzzwords of our time is misused most of the time (But that’s another story). UX is a much broader concept that describes, just as the name says, the experience a user has when using your product. As such security is an integral part of it. Guess what? If a user gets his account stolen because your very convenient signup flow didn’t tell the user that his password should not be “12345” their “experience” is sh*t. For some reason, security is not sexy and not shown in all those fancy diagrams that describe what UX encompasses.
The relationship between convenience and security does not necessarily need to be detrimental. The keyword here is usable security. Security needs to be built in our products in a usable way. Whenever this is not the case — and this often happens if the view on security is purely a technical one — users will find a way to misuse or deactivate security features in a way that maximizes convenience. In the worst case, if security is a very critical aspect of your product, they might also simply leave and go to the competition. There are plenty of examples of unusable security and how people circumvent it:
Ing forces users to set up a 6 digit key in addition to their password for login on their web platform. Upon login, a user is then asked to enter two digits of it using a virtual keyboard. This is probably done to avoid that users having a key logger installed on their system will give attackers access to their account.
Why is this bad?
- Its incompatible with password managers
- From a users perspective, this is just a second password resulting in a lot of users using passwords like 123456 (which is not checked) or similar because they only want to remember one
This is an example from real life. Looking at this picture you can see that this was not designed having the natural behavior of humans in mind.
Why is this a bad setup?
Imagine being a pedestrian on the “original sidewalk” on the left side of the photo. You just want to continue the but the construction site is blocking your sidewalk. This is what the creators of this had in mind for you:
- Wait on the traffic lights to switch to the sidewalk on the other side
- Walk to the next crossing
- Wait on the lights at the next crossing and switch side again.
Sounds like a lot of effort for so little distance. Naturally, everyone just takes the bicycle lane. Which makes the whole setup useless, clearly no one thought about how humans would actually behave when this was set up.
Get your mindset right
But what can we do to avoid such pitfalls? First of all, note what I wrote earlier, you need to get the mindset right — making your product secure IS improving the UX. Furthermore, I developed the following principles that help to build more usable security flows:
- Understand the situation and use cases
Not all security related flows are as ubiquitous as a login form. There are a lot of different flows, where misuse needs to prevented at all cost. It is important to understand the situations users might be in when they try to complete your flow. If you are a bank and design a flow for users to request a new card — consider that this might happen in a stress situation e.g. after a robbery.
- Think about the edge cases
What do users need to provide to complete the flow? Considering the above situations, will they be able to provide this. If not, what could you offer instead?
- What is the easiest alternative
Think about all the ways a user might misuse what you are building for convenience. Are there shortcuts? How do they look like? Why does this shortcut exist and why is it less secure? Can you make it as easy as the shortcut without compromising security? Can you incentivize users to not take it? Simply blocking shortcuts should be your last resort.
- Help users understand
For us, working in the industry a lot of cause-effect relationships are much clearer. The average user often has no awareness of the inner workings and potential attack vectors. Explain why it might be a good idea to set up 2FA. Convince users instead of forcing them.
Keep these things in mind and you will build more secure products while improving the general UX at the same time. A lot of the current security issues in the web could be avoided by improving the ease of use of our security flows reducing friction and thus incentivizing users to use them as intended. Let us build a more secure and more usable internet together — it benefits us all.