How to Build Secure Apps without Sacrificing User Experience

There’s been a long-standing debate on the trade-offs between User Experience (UX) and Security. We at Netguru believe that UX and security is not a zero-sum game. With the right approach, organizations can design user experience and security in complementary ways.

There isn’t — and will never be — a 100% secure solution. The right way to approach security is to identify and address the most common and dangerous threats. For web applications, which is the focus of our advice, most attacks are performed online.

In this guide, we identify security best practices against online attacks for you to consider as you deliver digital products that are both secure and delightful to use. This is ideal for product design teams, functional requirements analysts, and product owners.

Secure user behaviors through design

It’s vital for businesses to care about security and user experience holistically. One should not be at the expense of the other — and it doesn’t have to.

In the first place, consumers are becoming more conscious about digital security. Companies also have to comply with regulations such as the GDPR, which require “privacy by design”, among many other rules.

On the other hand, as we very well know from our clients at Netguru, enterprises and startups want user-friendly solutions to be competitive in the market. When the security features of an application are not user-friendly, users will exploit workarounds or they will simply switch to competitor apps.

A common theme you’ll find here is the idea of unintended consequences as a result of well-meaning security interventions. As you’ll see, and have probably witnessed or experienced yourselves, certain security features can sometimes influence user behavior in a way that negates these features and lead users to more harm.

This is why good design is critical in promoting secure user behaviors. Consider the best practices below when not only listing your application’s security requirements but also when designing for UX.

1. Use password dictionaries for good

Most log-in procedures are comprised of two components:

• Identification refers to claiming you are someone specific. This is commonly done through an email address or a username.

• Authentication is proving you are who you say you are. This is typically your password.

Most applications we use require a password to authenticate users. One key risk in applications that rely on passwords to authenticate the identity of their users is that these are susceptible to brute force attacks or dictionary attacks when a malicious hacker combines personal life details of the user with a password dictionary.

A Password Dictionary is a file containing a list of potential passwords, which could number into thousands or even millions of individual words, and most of them used in services already hacked. Hackers and penetration testers spend years building password dictionaries that grow to gigabytes in size and into billions of password permutations.

With the help of a password dictionary, a hacker with some knowledge of the target’s personal life can take as little as three minutes to identify the correct password. Most people tend to be lazy with their passwords and choose ones that are easy to crack with the help of tools readily available online, such as password dictionaries.

In protecting users, security professionals and UX specialists need to encourage them to create secure passwords. If malicious actors can exploit dictionaries of passwords, then it can also be used by companies to defend their users.

From the perspective of organizations as the product owners, the number one solution is to prevent users from choosing passwords that have been compiled in password dictionaries available online. There are safe APIs that can help businesses check if any given password has been leaked.

As a digital agency, we recommend to our clients to include detection of leaked passwords in their functional requirements. For instance, as you can see in the following image, if a user creates a password reported as compromised on other sites, the application must automatically prevent them from setting it.

2. Get rid of password complexity rules

You’ve likely experienced this: when setting your password, the app will require it to have lower case letters, upper case letters, a number, and a symbol.

The rationale behind it seems to have made sense before. But again, because of the tendency of users to rely on what they’re used to, password complexity can also be easy to guess.

Organizations should recognize this and flag their users that even when using alphanumeric combinations, some passwords can still be cracked.

3. Don’t require users to change passwords periodically

Similar to requiring password complexity from your users, requiring them to periodically change their passwords can have the unintended consequence of making passwords guessable.

As you can see in the example below, if an app forces their users to change passwords every year, what do you think the next password will likely be?

Changing passwords can have its benefits when users initiate it on their own and choose something completely different, but when it’s required by an application, users can establish a guessable pattern. When this practice emerged years ago, the intention towards security may have made sense, but the way users responded to it opened up a new opportunity for attacks. It’s probably a good time to get rid of this practice.

4. Display a password strength meter

Fortunately, password strength meters are a common practice. What we recommend is that the strength meter is not based requiring numbers or special characters.

Even if passwords are easy to remember, factors that increase its strength can include the following:

• Use of more than one word
• Use of pronouns or prepositions, and characters or words are separated with spaces

5. Log user activity, detect anomalies, and notify users

Once users create their account, applications should be able to detect anomalies, especially when signing in from a different device.

In addition, similar to how Google does it, applications should send a notification providing a link where the user can check activities on their account. This then requires that as part of an app’s functional requirements, its system should also be able to log account activity or history and users can view them.

6. Allow users to log out remote sessions

It’s a must for applications to be able to give users the ability to log out remote sessions. This is particularly critical when users lose their device or when there’s strange activity on their account.

Further, developers or engineers must make sure that the logout function actually ends the user session. This could have tremendous consequences when users remain logged in on public terminals despite having logged out, but the application fails to recognize this.

7. Utilize a third-party authentication provider

Cybersecurity experts always recommend that people use different passwords for different services. One solution that has been raised is the ability for apps to flag users when they’re setting a password they’ve used in their other accounts. However, this is not a user-friendly approach.

This supposed best practice of applying different passwords to different accounts forces users to handle security by themselves. The objective for product owners is to make security easier for their users.

To address this, digital services should utilize a trusted third-party authentication provider, such as a single sign-on (SSO) solution. This way, log-in and log-out requirements are transferred to a specialized tool whose job it is to guarantee digital security for your application and your users.

We highly recommend Microsoft, Apple, and Google’s authentication tools as they seamlessly integrate with the telemetry of most operating systems.

8. Go passwordless!

Consider resigning from passwords. Building consumer apps that don’t require passwords may sound unusual but it’s more common — and more secure — than you think. Going passwordless is entirely possible in web applications and even more widely used in mobile apps.

Multi-Factor Authentication (MFA) with poor user experience

Let’s first look at an example of Multi-Factor Authentication (MFA) that requires passwords as its first “factor” or requirement.

• This first factor is something that the user knows: a password, a PIN, or a security question.
• The second factor is something the user has or possesses: the device or hardware bearing a “key” or a one-time code that the user can easily generate. This factor is readily available and within the user’s possession.
• The third factor is something the user is: the user’s biometric information such as their eyes, face image, vein pattern, fingerprint, and even their behavior.

Strong authentication requires usage of two factors out of these three. The standard approach typically utilizes these two factors: something the user knows (e.g. password) and something the user has (e.g. one-time code generated on a mobile device).

Apps with two different factors are PSD2-compliant solutions. Payment Services Directive 2 (PSD2) is a regulation that payment services in the European Union (EU) must comply with.

Take GitHub for example, which developers know all too well. When logging in, users have to provide a password (something the user knows) and either a hardware key or a time-based one-time code (something the user has).

In this case, the responsibility for security is still predominantly in the user’s hands. While this is commonplace now among many apps, we feel that the user experience can still be improved.

Continuous authentication

The better solution is going passwordless. In a passwordless-compliant approach, the means for authentication lies in a process called continuous authentication.

Continuous Authentication is a means of granting users access to digital services on an ongoing basis based on contextual information and acceptable levels of risk.

In practice, the service requires something they have (first factor) and their behavior (second factor). User behavior is constantly monitored to check whether the device or key was not stolen and being used by someone else.

A lot of digital banks and fintech companies are already practicing this method. Their apps closely observe user behavior (something the user is) with the help of third-party providers.

The apps also use tools such as facial recognition or a fingerprint scanner (e.g. Touch ID for Apple devices). However, instead of using these as the ‘something the user is’ factor, these biometrics are treated as the ‘something I have’ factor.

The biometric data is not transferred to the bank’s servers. They’re only used to unlock the device, therefore treated as ‘something the user has’, not ‘something the user is’.

Notice as well that this solution does not require one-time codes. Nowadays, one-time passwords (OTP), especially those generated through SMS, can be intercepted or captured by an attacker. In a sense, OTP simply becomes another type of password.

The example in the image above shows the passwordless approach of Microsoft Web Applications. It uses either Windows Hello on the Windows OS or MS Authenticator on any mobile device. With a Windows OS, Windows Hello trusts the fact that a user is logged into a system with a hardware key. The MS Authenticator app is needed only for other operating systems. From the web app’s point of view, only one factor is being used: the device.

Similarly, using Touch ID in MacOS or other FIDO (Fast IDentity Online) hardware keys, together with WebAuthn protocol, also allows users to go passwordless in web applications. In this case, only one factor is checked: the device.

Again, biometrics are used only to unlock a device’s key. The fingerprint information is not being sent to the web app (something the user has, instead of something the user is). This makes it as phishing-proof as possible.

Security vs user experience vs cost — Choose two

While security and user experience can go together with these practices, this has to be weighed with another consideration: cost. Companies who don’t invest enough should expect either bad UX, bad security, or both.

We’re here to say that enhancing security for your users and delivering a user-friendly experience is worth the investment. At the same time, you can’t just pick between security and user experience because these two mutually reinforce each other.

Secure by design

It’s critical that organizations pin down security-related functional requirements before any digital product goes to development. If something is not specified, it won’t be estimated and implemented. While better user experience can be iterated, it’s best that applications are built with security as a prime consideration as early as possible.

If you’re working on a project that requires an experienced partner in security and user experience, we at Netguru have successfully built digital products for enterprises and startups around the world. Reach out to us, and let’s start a conversation.