On an average day, most employees have to log into numerous different applications and resources at work. The influx of applications necessary for work has led to an exponential increase in login and authentication methods, including things such as one-time passwords (OTPs) sent by texts or emails, magic links, biometrics, and much more.
Many authentication methods are even combined. To best protect important accounts and resources, it’s important to consider which authentication methods are strongest, as well as which ones will cause the least frustration for end-users. Azure AD (Entra ID) offers a unique feature called authentication strength that empowers administrators to determine the level of authentication they require users to utilize.
In this article, we’ll break down the meaning of authentication strength, which methods of authentication it considers, and how to use it effectively in your organization.
What is Authentication Strength?
Authentication strength is a conditional access control that allows Admins to determine which combination of authentication methods could be used to access an app or a resource. This gives administrators the ability to be flexible in authentication; they can choose stronger authentication methods for more critical resources, or weaker authentication methods for non-sensitive applications.
Microsoft defines authentication strength in three different ways:
- MFA strength
- Passwordless MFA strength
- Phishing-resistant MFA strength
MFA Strength
Multi-Factor Authentication (MFA) strength is the weakest tier of authentication strength. However, it also gives your users the most freedom in choosing how they authenticate to a given resource, as it supports the widest range of authentication options. The supported authentication options are the following:
- FIDO2 security keys
- Windows Hello for Business
- Certificate-based authentication (CBA, MFA)
- Microsoft authenticator app
- Temporary access pass
- Password + something you have
- Federated single-factor + something you have
- Federated multi-factor
Passwordless MFA Strength
Passwordless MFA is the middle tier strength-wise and can be used to eliminate the insecurity posed by passwords. It supports the following authentication methods:
- FIDO2 security keys
- Windows Hello for Business
- Certificate-based authentication (Multi-factor)
- Microsoft authenticator application
Unfortunately, since the authenticator app is often used on a smartphone, it can be difficult to implement this authentication method if you work in an extremely secure environment that limits phone usage. This would limit your authentication options even further, thus paving the way for the next authentication strength method.
Phishing-Resistant MFA Strength
Phishing-resistant MFA strength is the strictest authenticate strength level. It only supports the following authentication methods:
- FIDO2 Security key
- Windows Hello for Business
- Certificate-based authentication (Multi-factor)
Accounts that hold high-privilege administrative rights are frequently targeted by attacks, as gaining access to a single account with administrative rights provides enormous leverage to attackers. At a minimum, we recommend using phishing-resistant MFA on these accounts to reduce the risk of them being compromised.
Phishing-resistant method is definitely the most preferred way of authentication especially if you have a high security requirement. The below table lists the Pros and Cons of adopting each level of authentication strength.
Let’s deliberate on each of the authentication methods available and check on the one that lies on the extreme end of the positive spectrum. We’ll also examine the drawbacks and considerations that must be made before implementing each method.
Supported Authentication Methods & Considerations
Windows Hello for Business
This authentication type consists of a type of user credential that is tied to a device and uses a biometric or PIN.
It’s interesting to note how Windows Hello for Business works. It’s a two-step process that begins by registering your PIN or biometrics (facial, fingerprint, or iris) and then provisioning a cryptographic key pair (asymmetric) bound to the Trusted Platform Module (TPM) for each service that uses this authentication method.
When a user first registers Win Hello as the authentication method for an online service by entering the PIN/biometric gesture, only the public key travels to the service. The service makes a note of this public key-user mapping.
During the actual authentication to the registered service, the user enters a PIN or makes a biometric gesture as the first step. This would trigger the user’s computer to use its private key to cryptographically sign the request sent to the service. As the service already has the user-public key mapping, the user if valid gets authenticated successfully.
Drawbacks of Windows Hello
Windows Hello for Business only works on machines running Windows 10 and onward. If your organization has a mix of OSes or has legacy Windows OS devices, you need to plan a separate authentication method.
Furthermore, Windows Hello requires a PKI and Active Directory Federation Services (AD FS) to function over Key Trust and Certificate Trust models. The PKI allows for the generation of asymmetric cryptographic key pairs. While Microsoft does provide its own PKI solution in the form of Active Directory Certificate Services (AD CS), it is extremely difficult to build and manage your own PKI.
Introducing AD FS simply adds another layer of complexity to the architecture. Adding another server to the mix means an expansion of the threat landscape and another target for bad actors. It’s also a burden to configure and maintain AD FS servers, as well, consuming much of your administrator’s time.
FIDO 2 Security Key
FIDO2 security keys are hardware devices that contain cryptographic keys for authentication. The devices are typically USB but could also use Bluetooth or NFC.
FIDO is secure because it uses cryptography to authenticate users instead of passwords. Users need to register the device to the online service for which they would like to authenticate by making a gesture like pressing a button or giving their fingerprint. When they do so, they pass their public key to the service which in turn registers the same in the name of the user.
During authentication, the online service sends a challenge which the user counter signs with their Private key. This process is invoked by making the already registered gesture. The service then verifies the signature using the registered Public key.
Drawbacks for FIDO2 Security Keys
On paper, FIDO2 security keys seem very simple, but they also come with their share of security concerns. To begin with, they require completely separate hardware for storing the user’s cryptographic keys. This requirement for additional hardware creates its own plethora of complications.
For example, if the user loses the hardware, they would need to register all over again which not only costs the admin’s time but also requires the organization to purchase new hardware for the user whenever this occurs.
To prevent such costly hardware loss, administrators can require users to register a spare key. However, this is itself also another monetary cost. Imagine having to pay to essentially duplicate every single key.
Security keys also rely on the end-user completely for effectiveness. If the user forgets their key at home, they either have to go back and get it or lose access to necessary resources. Either outcome leads to a drop in productivity.
Finally, there is no way to tie specific key serial numbers to users in Azure AD. All that Azure can currently see is an authentication coming from a specific make and model of the key. In other words, keys could be wrongfully shared amongst employees of different access and authorization levels.
Microsoft Authenticator App
The Microsoft Authenticator app is another password-less authentication tool that provides either a notification or an OAuth verification code to sign into an application. You’ve likely seen similar authentication applications used for personal purposes outside of work. It looks like a notification on your phone that you then enter to access a resource.
Drawbacks of Microsoft Authenticator
Users might not be comfortable using personal mobile phones for official authentications. In that case, some organizations may opt to provide company-owned smartphones for their employees – but it’s easy to see how this could strain your budget.
Another issue is that Microsoft Authenticator requires employees to have a smartphone nearby at all times to be effective. Many secure environments restrict phone access, making this authentication method impossible.
Temporal Access Pass
Per Microsoft, a Temporal Access Pass is a time-limited passcode that can be configured for single use or multiple. Users can sign in with a Temporary Access Pass to onboard other authentication methods including passwordless methods such as Microsoft Authenticator, FIDO2, or Windows Hello for Business.
A Temporal Access Pass also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app, but needs to sign in to register new strong authentication methods.
Drawbacks of Temporal Access Passes
In practice, temporal access passes are rarely used to register or re-register a strong authentication method. This is because it requires an administrator to generate them and then share them with each user manually.
As the number of users grows, it’s easy to see how manually generating and sharing temporal access passes becomes time-consuming. In addition to the amount of unnecessary work they create, temporary access passes also become markedly less secure when shared with remote employees, as they will need to be sent over chat, email, or calls.
Passwords + Something You Have
This is a combination of two authentication factors: passwords and something you have, which refers to a text message, voice, push notification, software OATH token, or hardware OATH token. Passwords have been around since the internet was in its infant stages, and it’s widely known that, although they are simple to implement, they are also highly insecure.
By adding the second factor of something you have, this authentication method seeks to remedy the insecurity of passwords while still maintaining their simplicity. We’ll discuss what some considerations are with this option, as well.
Drawbacks of Passwords & Something You Have
The ‘something you have’ part of the equation requires users to always carry something along with them. Generally, this is a smartphone, and that leads to some of the issues we discussed with the previous authentication methods that require smartphones.
In extremely secure environments, smartphones are often not allowed. You also may find that some end users don’t want to use their own personal devices for work-related authentication.
But there’s also the risk of MFA fatigue to consider. In MFA fatigue attacks, users are flooded with MFA requests from an attacker, and simply end up granting access to the attacker after receiving too many requests.
Administrators may prevent the risk of MFA fatigue attacks by opting for hardware OATH tokens instead. In this scenario, however, administrators are required to manually bind user-token relationships by typing in the required details as mandated by Azure in a .CSV file and then uploading them to Azure. Once the file has been uploaded, they then need to manually activate every single token by clicking ‘Activate’ and entering the OTPs generated by each. This is extremely time-consuming.
Federated Single Factor and Something You Have
A variation of the aforementioned authentication factor can increase security but depends on how you configure it or which IDP you choose.
Certificate-Based Authentication (CBA)
Certificate-based authentication (CBA) uses certificates as part of the authentication process. Digital certificates offer several advantages over other authentication methods: they don’t require additional hardware for storage, they can stay securely on your device, and they allow for rapid authentication.
Unlike the other authentication methods, Azure has a ‘Trust’ provision for CBA, as well. Root and Intermediate Certificate Authorities can be uploaded to Azure for trusted authentications. There is also support for uploading a Certificate Revocation List (CRL) in a URL format, making it simple to add integrate all components of Public Key Infrastructure (PKI) with Azure AD.
Azure CBA works smoothly without any hurdles. You could also set conditional access policies for a plethora of customized requirements, which is the best option for your application security. Because specific device information can be encoded in certificate templates, you can be sure such policies are based on a strong foundation of device trust.
Certificates also provide an improved end-user experience, especially when replacing passwords. End-users don’t have to deal with the frustration of remembering, entering, or resetting passwords. This can be particularly beneficial for differently abled individuals or people with learning disabilities.
Drawbacks of Certificate-Based Authentication
The biggest barrier to deploying certificate-based authentication is having to build and maintain a PKI. Managing a PKI on your own is a difficult task that requires expertise and experience with cryptography. Fortunately, you don’t have to build a PKI on your own; with managed PKI services such as SecureW2’s, you can leverage the security of certificates without any of the hassle or expense that comes with building your own PKI.
Additionally, it’s possible for end-users to accidentally choose the wrong certificates or even cancel the certificate prompt at the time of authentication. However, getting past this possibility is simple: users can close their browser windows for a particular profile and open a fresh window. For instance, if you were working on ‘AA profile’ in the Google Chrome browser and ran into any of the aforementioned issues you’ll need to close all the browser windows of ‘AA profile’.
Implement the Highest Authentication Strength with SecureW2’s Managed PKI & RADIUS Solution
While certificate-based authentication is easily one of the most secure authentication methods supported by Azure’s Authentication Strength requirements, many businesses rightfully have concerns about deploying a PKI. If you were going to build your own PKI from the ground up, you’d find that it’s costly in terms of time, money, and knowledge.
But implementing certificate-driven security doesn’t have to be difficult. SecureW2’s managed PKI provides you everything you need to deploy certificates. Our complete certificate lifecycle automation platform gives administrators the technology they need to manage the entire certificate lifecycle from distribution to revocation. Plus, our PKI was designed to integrate seamlessly with Microsoft ecosystems, allowing you to leverage the policies and groups you’ve already created in Azure AD or Intune.
Want to learn more about what your network looks like with SecureW2? Check out how our PKI was designed to work with Azure AD or contact us today for a free demo.
