How would you like the idea of being escorted by armed security staff from the grocery store to your home in order to protect the valuable air fresheners you have just bought? Would you be confused, would you visit the store again?
On our plate today: The art of balancing security and usability.
Accordingly, in software design, usability is quintessential. When users decide to go with your product/service instead of the competitor’s, usability is usually the main driver behind their decision. If you want them to be long-term users, you need to build a foundation of trust. Brand loyalty rests upon nurturing credibility through crucial components: honesty, transparency and brand safety. Your product/service needs to be reliable, available, privacy-conscious and secure. All of these factors are intertwined with one another, and finding the right balance between security and usability for your product/service is up to you. This article takes a look at the effects security requirements have on the rest of your application and shows different ways on how to negate or take advantage of that impact.
If the usability of security features in your application is weak, users will try to avoid or bypass them.
However, if done correctly, security does not impact usability, on the contrary, usability actually increases security.
Do not overwhelm your users with security options at the beginning, just enable the options you would like them to use. They can opt out later if they want to. Users inherently want to stay safe, but in most cases, they don’t have enough in-depth knowledge to make the right decisions. Antivirus softwares usually approach this the right way: they give a simple slider with 3 strictness levels with “recommended” in the middle, as the preselected default option. This is a great way of hiding the complexity behind it while educating users about the consequences of their security choices.
After many years of UI interaction, users will expect a certain type of common functionality from your app, which is both a curse and a blessing. A curse because any new functionality you introduce will require you to invest in educating the users, but a blessing because they will not be discouraged by security requirements that they have already come across on Facebook and Google.
Therefore , when users expect a certain type of behavior to occur, do not alter that said expectation unless absolutely necessary or it will indirectly reduce security.
The state of your application should always be identifiable to users. In the middle of a workflow, users should be able to see they are logged in, on every page.
This will help to mitigate phishing attempts trying to pose as your application.
Do not ask for actions that can be postponed or rarely need user interaction. Be reactive to user behavior.
Security has to be built into systems from the beginning. This means product designers need to be familiar with security requirements at a high-level. When you have wide variety of user roles and permissions, you need to make sure each user understand the extent of their role. It may seem convenient to add a delete button on an otherwise read-only page just for administrators, but this can make your admin users take the delete actions less seriously or make them think that deleting is a functionality available to all users.
Even more important: listen to user feedback directly and in an automated way. A common mistake developers make, is they focus only on existing users and forget about the potential new ones. Users with a high churn rate rarely give feedback. However, with A/B testing and usage analytics, you can identify the exact moment when you lose customers. For instance, one reason might be because of a strenuous registration process.
The farther out of reach your features are from your users, the harder it is to maintain usability. The login process is one of the biggest hurdles and requires utmost attention. Here are some commonly used methods to reduce its impact on usability.
Security’s focus should be the on “how” instead of on the “who”, because the key is prevention, not acting in hindsight. Following this principle, higher level of security will only enhance privacy. Some critical areas to consider:
This is a symbiotic relationship, we cannot have security without reliability, and vice versa. Let’s take a look at how we can have these two play along nicely.
A security incident will always affect your system’s availability and you need to have an action plan to minimize the harm it can cause. Have backups and snapshots available – not to be confused with replication.
The lack of proper security in an application tends to indicate much larger problems behind a product which users eventually notice. These problems can be insufficient time for development, miscommunication, lack of planning or knowledge, etc.
Until these underlying problems are addressed it is usually not possible to achieve security discipline, which is key to switch from a reactionary behavior to a preemptive one.
However, here are some quick tips that will help any team make fewer security mistakes.
Use well-established 3rd-party solutions unless you’re creating a security solution yourself. Even respected and well-reviewed libraries such as OpenSSL can have serious, unnoticed vulnerabilities in them. It is unlikely that an in-house solution can live up to the same standards and maintain them.
Some security requirements do not need to be tied to your application’s business logic. These can be separated from your application and implemented on a much higher level either by you or a 3rd-party. Some of these include:
Integrate security scanning into your development workflow:
Even if you lack knowledge for an in-depth pen-test, at least create a checklist of things to verify before major releases. The OWASP Testing Guide is great to start for beginners.