Authentication Security: The Benefits of a Broader Perspective

We keep hearing about password mishaps and compromises leading to security breaches involving stolen credentials. But that’s only the tip of the iceberg. You can just read some application security articles to learn about the perils of compromised passwords and experience sleepless nights. They are responsible for 61% of hacking-related breaches. Let’s take a closer look at passwords and their impact on authentication security.

We have become hard-wired to protect our software with emails and passwords over the years. Simply put, it has become second nature. We have gotten used to entering email and passwords in the SaaS products we are using. This may have been fine a decade ago, but the average person today uses dozens of applications. What happens when we sign up for yet another app asking for our email and password? 

We do one of the following:

1. Use the same password we have chosen for EVERY(!) other product we are using. 53% of People Admit They Reuse the Same Password for Multiple Accounts. This in itself is a big authentication security risk.
2. Use a new generated password and store it somewhere. Where do we store our new awesome password? If you are using a password manager, good! But keep in mind that they can be breached as well. 

Not using a password manager? Well…

So if I wasn’t clear enough earlier in this article – we need to stop using passwords. We keep hearing about this from security professionals, UX experts, and engineering colleagues. In other words, all roads lead to passwordless authentication.  But let’s try to dig a bit deeper and examine technically why we want to stop using passwords and how we want to authenticate the “passwordless” way.

Related Content: Read Our HMAC Guide

Password Authentication is Flawed

In order to get into and go through “passwordless rehab” successfully, we MUST understand why the older way of implementing and supporting passwords is so complex to build from the developer’s perspective.

The Challenge of Saving Passwords

The first step you need to take for maintaining passwords is obviously saving them. We need to hash and salt them, while using mechanisms like bcrypt, scrypt, or argon2. That means putting an effort into calculating the required key factor size AND putting CPU efforts in validating the password every time the user wants to authenticate. All of this needs to be done on an ongoing basis in real time.

Sounds like fun?

Well, passwordless authentication solves this problem instantly.

Supporting Reset Password Flows

If you thought storing user passwords is fun, how about implementing yet another flow? You have the reset password flow as well. When the end-users forget their passwords (and this happens more often than you think), password resets are required. The reset request is sent via an API. What does this mean? You are basically sending the user a reset password token, with which they can reset the password. 

Sounds pretty straightforward right? Well, think again!

How will you be protecting the reset password API? 

• It should be rate-limited as this API is an unauthenticated API 
• It should be protected from user enumeration as we don’t want attackers to list and map the users that exist via this API
• It should be protected by anti-automation tools (such as reCAPTCHA)

And that’s even before we start thinking about how to implement the reset password token mechanism. Here are just a couple of roadblocks:

• Where do we save the token? And how? Reset password tokens are just as vulnerable as passwords in case of DB hijacking. We need to make sure we are using the same hash and salt mechanisms when we store them.
• What is the length of the token we want? What is the time slot we allow for these tokens to live? We want to minimize token spraying attacks by increasing the token size and reducing the time slot to mitigate these.

Supporting Password Complexity Rules

When end-users choose passwords, they often forget about the authentication security aspect, rather focusing on ones they can remember easily. Here are the 50 most used passwords (revealed in a massive 10 million password leak). People are still going with “12345678”, “password”, 123123”, and “111111”. Quite shocking.

The only way to “push” users in the right direction and overcome this issue is by implementing rules to ensure password complexity. But unfortunately, this involves additional steps that need to be taken while signing up or logging in. This elevated friction increases churn, while reducing customer satisfaction. 

How is this implemented? There are some common options:

1. Following the OWASP password length and complexity security principles. This sometimes comes in the form of customer requests and requires varying levels of granularity to fit multiple use cases.
2. Implementing pawned passwords API in order to enforce breached passwords detection and to allow end-users to change passwords while detecting passwords breaches.

Brute Force and Password Spraying Protection

One of the most common attacks related to passwords is called Password Spraying (basically a brute force attack variation). In this type of attack, the hacker will brute force logins based on a list of usernames with default passwords. This attack can be found commonly where application vendors or admins set a default password for all new users, a risky practice that still exists.

Now that we know what password spraying attacks do, how do we mitigate them?

1. Apply reCAPTCHA – Apply anti-automation tools such as reCAPTCHA to protect automation scripts and to make sure that there is an actual human on the other side performing the application login.
2. Apply Lockout Mechanisms – Once we detect several wrong password attempts, we would like to lock the user (and notify them via email). This method can prevent unauthorized access to the account. 

Degraded User Experience (UX)

One of the most common challenges with password-based authentication is the user experience. There are a bunch of screens you will have to implement: Forgot password, Reset password, Activate account with password, and more. All of these are bound to product decisions on how we want them to look. For example, should we add a back button to the login view from the reset password screen or not?

Additionally, as the number of SaaS services grows, the UX issue becomes more complex. There is no real standard on how a reset password or activate account scenario should look like. Products we use online behave differently.

Migration Options

There are also times when we want to migrate between third-party user management services. 

This leads to a wide range of operational and authentication security challenges.

In most cases, the passwords are saved on the services as salted and hashed. That means that migration between different user management services will require all end-users to reset their password, a frustrating and time-consuming process. This obviously is not an issue when dealing with passwordless authentication, as we just send the user another authentication link.

The Future of Authentication Belongs to Passwordless

Now that we have covered the pain points that password authentication introduces, let’s run over the advantages of passwordless authentication. 

1. Improved User Authentication Security 

With no passwords in play, hackers have a reduced attack surface to exploit. This in itself is a big step in the right direction. By eliminating phishing, ransomware exploits, and other types of cyberattacks, you can also easily achieve sustainable data privacy compliance. GDPR in the European Union (EU) is not optional anymore, nor are the CCPA and HIPAA regulations in the United States.

2. Allow Users to Focus on the Product

We all forget passwords. By using passwordless authentication you allow your user to focus on what really matters and improve their user experience when signing in to the product by using a magic link or a 6-digit code. They no longer have to remember multiple passwords, nor do they have to waste valuable time resetting forgotten ones. With passwordless, the focus is solely on the product.

3. Passwordless Elevates Productivity 

The numbers don’t lie. Let’s assume that you have a team of 100 developers. How would you react if I told you that each one of them is spending almost 11 hours annually resetting passwords. That’s 45 days in a year for the team. Things get worse when you are an enterprise-level organization with thousands of workers in multiple locations.

As per a recent research, the estimated cost of productivity per enterprise organisation is $5.2 million annually on average. 

4. Streamline Your Workforce

More and more research is pointing at the cold truth — around half of ServiceDesk requests are password related. With passwordless, your support team will spend less time helping customers reset their passwords and focus on other tasks that can elevate customer satisfaction (no ticket backlogs). With passwordless authentication, they can operate with frictionless authentication.

5. Move to Next-Gen Authentication Security

The world of identity management is going passwordless. Gartner has already officially stated that “60% of large and global enterprises, along with 90 percent of midsize enterprises, will implement passwordless methods in more than 50% of use cases by 2022 — up from just 5% in 2018.” The numbers don’t lie. Password authentication’s days are numbered.

Passwordless is the Next Big Thing

It’s pretty clear that the future belongs to passwordless. With more and more services and platforms becoming digitalized, the password authentication model is simply not practical anymore. Embracing the passwordless trend and implementing it as a default option in self-served and multi-tenant offerings (think user management) is no longer an option. Authentication security is in your hands.