Types and strengths of the various Okta authentication methods

When you are an admin at an Identity provider platform such as Okta, your first and foremost concern is how strong your current authentication and authorization strategy is.

Everyone who has been in that position has recurrent nightmares about your company being breached and your name appearing on the news. Like many say in the security world, it is really not a matter of if, but a matter of when. And when it happens, your safeguards need to be strong enough to minimize the blast radius, so the bad actor cannot get far.

‍‍This is where a platform like Okta can help. In this series of authentication articles, we will walk through how Okta enables the configuration of multifactor authentication with minimal effort, authentication methods available, and how you can configure a first iteration for your company.

Okta’s authentication factor types

Today, Okta provides the following three authentication factor types to choose from: 

• Possession: this is something the user has, such as a phone or an e-mail account, and has previously verified ownership of. 
• Knowledge: this is something the user knows, such as a password or the answer to a security question.
• Inherence: this represents a physical attribute of the user, such as a fingerprint or face, that a device can scan to verify against a previously saved digital representation.

‍Okta provides a cheat sheet listing all supported authenticators by factor type:
‍

We will take a minute to examine the two Knowledge factors: Password and Security Questions.

Using security questions as a factor is strongly discouraged today by Okta and all identity providers. This is because security questions’ answers can be easily discovered as they are based on personal data and intruders can use many techniques such as social engineering, phishing, or just plain guessing to find the answers. Sadly, there are still many legacy systems today which leverage security questions. If they are part of your strategy, please do yourself a favor and come up with a plan to replace them with a stronger factor in the next 1 to 3 months.

For a long time, passwords were the only construct to prove your identity when gaining access to a system. Fortunately, times have changed. As a rule of thumb, knowledge factors such as password or security questions are considered the weakest factors. Why? Because even systems secured by strong passwords can be cracked based on brute or dictionary attacks.

For context, a brute force attack consists of a malicious actor trying to crack a password using every possible combination of characters which is resource-intensive. However, I have seen dictionary attacks gain a lot of traction in the past few years and have experienced them firsthand in systems I supported. They are not as resource-intensive because instead of trying every possible combination, the hacker leverages a list of commonly used words, phrases, or character combinations. Many times these bad actors get a hold of lists containing actual, real passwords people have used somewhere on the web.

The hacker then attempts to break the target system by trying the passwords in the list in the hopes that one or more of the users in the system in question has used one of those passwords. Once they get a hit, they have not only gotten access to the account in this system but can also reuse the set of credentials in other systems to try to gain access. Because people reuse credentials all the time, they have a pretty good chance to get through any other systems where the user’s credentials are the same, unless the systems have enabled additional checks.

This is where multi-factor authentication comes in.

A proposal for a more secure system

Now, let’s go through a first iteration of how you can migrate a traditional system to a more secure authentication strategy.

For this exercise, we will select a combination of factors that takes into account the fact that traditional systems usually rely on a password. I know we just said passwords are weaker than other factors but they do have a place during migrations when your company user base is set on their ways and want to configure something relatively quickly. In this case, adoption of 2nd factor authentication (2FA) would provide a relatively smooth transition for your company’s employees to a more secure authentication profile without a huge configuration rollout or user learning curve ramp-up.

To provide your employees with a familiar authentication flow, we will keep password as one of the factors and will add an authenticator app as the second factor from the possession category. Depending on your company’s technical strategy and current vendors, it may make sense to choose one that aligns with the current stack supported or possibly from a vendor you are already engaged with for other activities.

For example, if they leverage the Google Suite of services, they may decide to go with Google’s authenticator. For this use case, we will leverage the Okta Verify authenticator app since we are already leveraging Okta as the company’s workforce identity provider.

Preparing your Okta user base

At this point, you should already have your users in the Okta tenant you are trying to improve your security posture for. If no groups have been defined yet, please go ahead and do so as you should be assigning authentication policies to groups and not to individual users.

Managing users one by one can become cumbersome quite quickly and it is much more difficult to keep track of all the changes and who has access to what. As a best practice, always create a group even if you will initially be assigning only a couple of users. To create a new group, locate the Groups option under Directory in the left menu. Then, enter a Name and Description following a set naming convention for your company, proceed to create the group and assign the appropriate users by clicking on Assign people. Just to make it fun, I used hobbit names from The Lord of the Rings trilogy as I am a big fan.
‍

‍

Configure 2F authentication step-by-step

Once you have your groups, you can start the authentication configuration. The first step is to make sure you have the 2 selected factors added.

To do this, go to Security -> Authenticators, locate the Password authenticator and click on Actions -> Edit. Okta provides you with a Default Policy that requires a basic Password lacking any complexity. You should create a new Policy by clicking on Add New Password Policy and add a set of rules. You can see the sample policy and rule I’ve created below.

‍I recommend you to require a mix of lowercase and uppercase letters plus numbers and symbols, but you can follow whichever requirements you have defined for your organization, just make sure they are strong enough.
‍

Note that for Password Change, you can proceed without extra factors since the user has been already authenticated at this point.
‍

On the other hand, if you enable a Self-Service Password Reset flow, you will need to configure  extra factors. I have set that it can be initiated from an Okta Verify Push notification or Email for our purpose but you can require an additional verification via any enrolled authenticator used for MFA/SSO.
‍

‍

Your tenant authn security blanket

Now that your Password authenticator policy and rule(s) are defined, you will define your Global Session Policy.

We will discuss the different types of policies Okta offers in a later article focused on policies but for now it is good to understand that Global Session policies apply globally to your whole tenant and dictate who and how a user is authenticated to Okta, including factors presented and how many factors are required. It also defines duration for the user session.

You can definitely configure other types of policies called Authentication policies and become much more granular and intentional by allowing or denying access to specific applications and adding or removing groups and users.

Now that you understand what global sessions are and why we need them defined, let us configure a Global Session Policy and corresponding rule. To do so, go to Security -> Global Session Policy.

If you examine the contents of this page, you will notice that Okta provides you with a Default Policy out of the box as of today. We will be creating a new Policy and rule that will require our hobbits to present a password and a second factor with Okta Verify as the authenticator app.
‍

‍

Notice a few details in these screens. We are setting up our MFA lifetime to be 1 week (7 days), but the global session is set to expire every 5 days (thinking of a typical work week). The MFA lifetime will be enforced when a new session is created or if the user device changes. It is recommended to always set a session idle time and in our case this is 12 hours (slightly longer than a work day).

As simple as that, we have configured a global session policy that will apply all the hobbits in our Shire group. Let us now take you through what your employees will see when logging in for the first time.

A hobbit user journey

Let’s say a new hobbit employee called merrybrandybuck@theshire.com starts on his first day. He can’t wait to join Frodo and Pippin and the other hobbits in their quest but he still needs to get access to all the systems required to go on the adventure of a lifetime. An admin, let’s say Frodo, has set up Merry’s account, and Merry has his super cool LOTR e-mail and temporary password.

At this point, Merry will need to authenticate with the temporary password, select a new password and proceed to enroll his required second factor, Okta Verify. The following screens walk you through what Merry will see:
‍

‍

Depending on Merry’s device capabilities, he has the option to enable biometrics so next time he is asked for MFA he can proceed with a face or fingerprint unlock which makes the process much simpler and less of a hassle.

If not enabled, he will need to enter a code from the Okta Verify every time MFA is required. Of course as long as the device supports it, he can go back to the Okta Verify app and enable biometrics later.

Once both factors are successfully verified, Merry is landed in the Okta Dashboard and can see the apps he has been granted access to.
‍

Voilá!

Getting your first iteration to prime time

To test this authentication flow, you can roll out a Pilot at your company by enabling the new experience to selected users in a test group, or/and segments of your network.

I always recommend you test with a small sample of users and not do a Big-Bang deployment approach, especially with Identity authentication, as this allows you to gather feedback from the users before turning the approach into your standard authentication flow for everyone in your company.

Next steps

In this article, we set out a premise you can explore to improve the security posture of your Enterprise in a relatively short amount of time. Please keep in mind that this is a first iteration to consider and there are many other combinations that would also be valid.

Also, always consider the user journey itself and how much friction any added factors may add to your user experience. Although there may be industries where you constantly need to verify your users via multiple factors such as Government or Military entities, in most other cases your users will suffer from MFA fatigue if this is triggered all the time. When setting your lifetimes make sure to account for this.

Okta offers much more advanced options such as Risk-based authentication and Adaptive MFA which you should absolutely take advantage of. This will enable much faster and friendlier flows that your users will love. We will cover these and the different types of policies in Okta in articles coming soon. Looking forward to seeing you there!