Jump To Section
Have you ever ended up abandoning a product because it forced you into multiple, seemingly unnecessary security layers?
Let’s take an example of what I’m talking about. In fact, I’ll share four examples of how security layers meant to “enhance security” can cause more harm than good.
Product Security Layers That Do Not Work
1. Complex Password Policy
Back in my college days, this is what the password policy of our IT department looked like:
- A default password was set up for every student, which looked something like this: Press@123
- All students were required to change this password every month
This was a classic example, and not the only one, of a complex password policy that both required symbols, numbers, upper and lower case letters, and also required the users to reset the passwords at an interval of every few days.
As a result of this, most users would end up using the same passwords across various websites and, in worse cases, saving their passwords in unencrypted notes.
This wasn’t the only consequence of the complex password policy adopted by my college IT department:
A massive worldwide online hack took place during those days, due to which a staggering 8 billion login passwords were leaked.
I, along with some friends, downloaded and analyzed this dump of account login passwords. A key observation we made while analyzing these passwords, which belonged to university students, professors, and even cyber security product experts, was that every time these users were asked to reset their passwords, they would only increment the last number in the password.
If this event proved anything, it was how user behavior could easily render such complex security measures redundant and useless.
2. No ‘Show Password’ Option
Apple users, in particular, will be able to relate to this issue the most.
The unavailability of a ‘show password’ option often results in users opting for other, non-secure ways to avoid typing errors when inserting their passwords. Oftentimes, users are more likely to simply copy and paste their passwords from other non-encrypted places where they’ve written down these passwords, mostly their notes.
Another consequence of a missing ‘show password’ option is that users end up creating short, less complex passwords that are easy to remember as well as type out without mistakes.
Fortunately, to prevent such counter-productivity, many platforms have equipped users with the capability to ‘show password’, which is enabled as a default feature so as to minimize errors and enhance the user experience without compromising on the security of their passwords.
3. Frequent Logouts
In efforts to prevent misuse of account information, a lot of applications and platforms frequently log out the users after a certain time of inactivity (or, as per their own respective policies, even every week or month, etc.).
While the need for such policies is evident in sensitive cases like banking and finance apps, these measures can hamper the user experience and end up being an overkill for other use-cases, like HR software or other internal applications.
Thankfully, as a solution to this dilemma, we have technologies of Face and Touch IDs to deal with such concerns as they don’t compromise on the user experience while keeping security intact.
4. Prohibited Multi-device Logins
There are also some applications that will automatically log you out from one place if you try to log in from another device or IP address.
This, again, hampers the usability of the application and can be off-putting for users.
A better implementation of this, rather than automatically expiring the user sessions, is where users are allowed to add and remember any new device that they log in from. Once they go through the verification for the new device, they can simply ‘remember’ that device, so they don’t have to log in every single time.
Product Security and User Experience: Finding the Balance
The dilemma of choosing between amping up product security versus accounting for better usability and an improved overall user experience is one that we often face in our daily work.
According to Avi Douglen, founder and CEO of Bounce Security, AviD’s Rule of Usability posits that:
“Security at the expense of usability comes at the expense of security.”
The Pessimists Vs. the Optimists
There are two sides to this dilemma that stems from the plight to balancing usability and security:
The Pessimists:
These are the Security and IT teams whose belief lies with Murphy’s Law, meaning that what can happen will happen. So, being preemptive, the Pessimists will want to ensure Government-level security for all apps.
The Optimists:
On the other hand, there are The Optimists. These are the Design, CX, and Sales teams whose primary job is building products that engage the customers and are easy for them to use rather than adding more barriers and complications for the user.
Which of these two sides comes out at the top?
Neither, because both of them have weight, and both are (usually) valid in their own ways.
Is the Minimum Viable Secure Product (MVSP) Worth It?
For Product Managers, the most vital thing they need to achieve is to find a balance between usability of the product and its security. This sweet spot between the two is what has come to be known as the Minimum Viable Security Product.
Exactly where this balance is achieved will always vary according to the situation and circumstance at hand.
For example, some products involve Personally Identifiable Information (PII) or other data that is of high sensitivity. In this case, a product manager may need to lean more towards The Pessimists and adopt a layered security model, endpoint security controls, or another stringent product security framework.
With that said, what is of utmost importance here is to not ignore either side of the coin.
Often, finding this balance between product security and usability may require you to adopt measures that are costlier.
From personal experience, and having learnt the hard way, I’ve found that identifying and choosing such a solution that does the job of keeping both usability and security intact is often worth the added cost.
I’ve also found that oftentimes security teams can get lax and suggest a security measure that damages the user experience, while better alternatives do exist that can at least come close to achieving similar levels of security.
All that would be required to achieve the latter rather than the former is some added effort (e.g., HTTPS, local storage encryption, app bundle encryption, etc.).
Takeaway
In the presence of so many innovative solutions that product teams now have at their disposal, balancing security and usability is not the impossible, gargantuan task that it was previously believed to be.
In some cases, you might need to encourage and challenge design teams to innovate for an enhanced user experience amidst security constraints. It’s safe to say that seeing how long we have come with technological advancements, solutions like Passwordless logins, Face IDs, Touch IDs, MFA, SSO, and more have made it possible to achieve the right balance between security and usability.
FAQs
What is the Minimum Viable Secure Product (MVSP)?
Minimum Viable Security Product (MVSP) is the baseline of the minimum security measures and checks that a product must meet to ensure security. Much like the need has grown from simply providing a minimum viable product checklist to instead creating a Minimum Viable Experience, so has Minimum Viable Security become more relevant and required to create a safe minimum viable product.
What is the Minimum Viable Secure Product checklist?
For any software, application, or enterprise-ready products and services, a Minimum Viable Secure Product checklist is a baseline for security measures that can be implemented at various stages of the product and sales cycle. These security controls help manage the security levels for things like requests for proposals, self-assessments, third-party security, vendor compliance, licensing, etc.
