Zero Trust With Strong Passwordless Authentication Using Curity and Beyond Identity

The movement towards a passwordless world has finally gained some momentum. Passwords have been the primary form of authentication for decades, but they have always been plagued with many issues and vulnerabilities. Now, several solutions in the market allow organizations to securely and seamlessly move away from passwords.

Many organizations are adopting a Zero Trust Architecture wherein user identity must be verified frequently. In this paradigm, the use of passwords is far less than ideal. So let's break down the problems with using passwords and consider a seamless, user-friendly alternative.

The Problem With Passwords

Passwords are a type of shared secret. A user registers their passwords for an application, and the application stores that password. Later, when it's time to authenticate, the user presents their password, and the application compares the provided password with the stored password. This is the most simplistic way of looking at it.

So far, so good. It's pretty easy to set that up in an application. But this is where the problems begin. Let's take a closer look at some of the more prevalent problems with using passwords for authentication.

Storing Passwords

It would be a bad idea to store the passwords in clear text in a data store that the application can access and use. The mechanism for handling that would be to encrypt/hash the password. However, this does still sometimes require the application to pass the clear text password between different components in the app. This could end up being something an attacker could exploit to obtain the clear text password.

Sure, it's possible to ensure this process is done correctly, but most app developers are not security experts. They simply want to develop an app to be the best at what it's supposed to do and aren't always considering security, authentication, and authorization.

Password Complexity

The easy aspect of using passwords is that users can typically recall them. However, passwords that can be remembered are easy to brute force or even reverse engineer. Modern computing power can be leveraged repeatedly to attempt to re-create the encrypted or hashed version of the password. Hackers can use a dictionary to feed the process with common words, making it even faster to crack trivial passwords.

So, how about using more complex passwords? That might somewhat solve the problem of cracking the passwords, but it becomes virtually impossible for a user to remember a password. Here's an example of a pretty good password: pxwZyb9i3sS*iZe2om568NKLm%&7tJc7HK^abWnw (no need to try anywhere, it's not a password I use :) ).

This typically influences users to write the password down somewhere. Regardless of where and how that's done, it's never a good idea. Password managers are another option that is better than a sticky note, but they come with their own set of issues. A password manager must be protected somehow, usually with... a password. Password managers also typically require an application to be installed. Lastly, the copy and paste process between the password manager and the target application can be tedious.

The "Same Password Everywhere" Problem

Users can probably memorize a few complex passwords, but it would be challenging to do this for all online services and apps that we use these days. Personally, I have counted up to almost 300 apps where I have some form of password for authentication.

A common approach then is for the user to re-use the same password for many applications. However, this creates a problem where if the password is compromised in one application, all the other applications where the same password is used are also compromised. Some applications are probably better at protecting the user's password but far from all applications are.

Passwords and Zero Trust

A Zero Trust approach requires frequent identity verification. Authentication is the process of determining that the user is actually who they say they are. In a Zero Trust Architecture (ZTA), services and applications need to verify who is requesting access to a resource at every access attempt.

Using passwords would not be user-friendly for this continual verification. It would require the user to authenticate repeatedly, taking much time and introducing a headache if complex passwords are used. Even with a password manager, it would be cumbersome to retrieve the password from the storage with every authentication.

A Standards-Based Approach

OAuth and OpenID Connect are fundamental standards for protecting APIs. Instead of relying on passwords, these standards use tokens to protect APIs, which works well for both services and users accessing resources. A token-based architecture also maps exceptionally well to handling a Zero Trust Architecture.

Where OAuth provides the foundation, OpenID Connect (OIDC) is an identity layer on top of OAuth that handles identifying the user. Solutions that support standards are often straightforward and seamless to integrate. Both Beyond Identity and Curity support OIDC and, as such, are very easy to integrate.

Integration by Configuration

The Curity Identity Server provides several authentication options out of the box, including an OIDC Authenticator. Beyond Identity supports OIDC in different areas of the product as well. This allows for simple integration between the two products using configuration only. No custom code is required — no need to use any SDKs to build a custom plugin or other custom integration. As outlined in the documentation, a simple configuration on both sides is all that's needed.

Curity provides a robust token-based architecture to achieve solid protection of APIs and a Zero Trust Architecture. That, coupled with seamless passwordless user authentication provided by Beyond Identity, completes a best-of-breed ZTA solution that places the identity at the center of application security.