This is part 2 of 4 part series. If you haven’t read part 1 of the blog series, I suggest reading it first: go to part 1
Not all authentication methods are created equal. Microsoft Digital Defense report from 2023 lists multi-factor authentication as one of five key protection controls against cyber attacks. As leaks like recent Okta and LastPass breaches are becoming more and more common, authenticating with password alone seems absurd to me. Even if it’s a really good one. I would take authentication safeguarding a step further by removing weak authentication methods altogether. Let’s start!
Setting the goal
In part 2 of the blog series we will go through the available authentication methods and how they work. Then we’ll make an argument for passwordless authentication. At last, we’ll look at two concepts: Authentication Strength and Authentication Contexts and link those to the some example scenarios.
Authentication methods explained
The following chapter is an explanation of the authentication methods and what they can be used for.
Microsoft Authenticator app
Note! Microsoft is planning to add support for passkeys to Microsoft Authenticator app in an upcoming release! Hopefully, we would see phishing-resistant Microsoft Authenticator app somewhere in 2024.
Microsoft Authenticator app is available for Android and iOS and can be used for authentication in three different ways:
- Push notifications as a second factor for either MFA or SSPR
- Verification code as a second factor for either MFA or SSPR
- Passwordless authentication, previously more commonly known as Microsoft Authenticator app phone sign-in.
Notice that Microsoft Authenticator app is not yet phishing-resistant, even if the ‘Authenticator (Phone Sign-in)’ is listed in the ‘Best: Passwordless’ category!
Push notification
Many of us are using push notifications today. During the sign-in process, after the username and password, you’re prompted to match the number on the screen by entering it into the Authenticator app. Earlier user would only approve or deny the sign-in attempt. Adversaries abused this in a DDoS fashion which resulted in MFA-fatigue on users who would approve the prompt just to be able to get rid of the notifications. At the time of writing, number matching has superseded approve-deny functionality since it was released on May 8th 2023 and is currently enforced on all tenants by Microsoft.
Note! Starting from August 2023 sign-ins that are interpreted as anomalous, do not generate notification for user’s phone. This means that users are less likely to approve anomalous sign-in prompts as they do not attract user’s attention. Sign-ins that are deemed anomalous, for example benign sign-ins (suspicious, but expected), can still be approved from the app by the user.
Verification code
Microsoft Authenticator app provides software token functionality. It generates OATH verification codes that can be used as a second factor in the sign-in flow, also during the SSPR flow. See below pictures that illustrate the flow of using verification code instead of push notification. I cannot think of a good reason or scenario where I would rather user verification code over push notification with number matching.
Passwordless (Phone Sign-in)
Passwordless sign-in essentially means that instead of seeing the password prompt after username input, user sees a message with a random number which they must enter in their authenticator app. This authentication method satisfies both first and second factors, as it requires ‘something you have’ (your phone) and ‘something you know’ (the number that must match) and ‘something you are/know’ (Biometric or PIN). Passwordless sign-in method requires user to register your device (typically phone) with organization’s tenant.
Managing Microsoft Authenticator app
As one could imagine, there’s administrator control for this authentication method and how it is controlled depends on how the authentication methods as a whole are controlled in an organization. I’ve written a blog post about migrating legacy policies to unified management, and if the topic is not familiar you should add it to your reading list.
- If the organization is already using unified authentication method management and none of the legacy controls, then administrator can configure it from Microsoft Entra ID portal (https://entra.microsoft.com): Protection > Authentication methods > Policies > Microsoft Authenticator (Figure 1). To enable passwordless administrator needs to choose either Any or Passwordless. If Authentication mode is set to Push, then Passwordless is disabled.
Furthermore, administrator can configure the behavior of the app from Configure tab (Figure 2). I recommend to enable application name and geographic location also as they don’t clutter the prompt, but instead provide useful information that might make the difference between user completing the number matching prompt or reporting anomalous sign-in attempt. Unified authentication method management is preferred way to manage authentication methods and only way to truly manage them at scale while having flexibility to include/exclude users or groups.
- If the legacy controls are still in use, I recommend first going through the migration process to unified management because on September 30th 2025 these legacy controls will be deprecated. The difference between unified management and legacy controls is that with legacy controls you can only make tenant-wide configurations and cannot configure Microsoft Authenticator behavior. All and any controls over Microsoft Authenticator app with legacy controls are almost nonexistent. The ‘Verification code from mobile app or hardware token’ and ‘Notification through mobile app’ are the only checkboxes you can fiddle with regarding second factor MFA. The situation is very similar with SSPR controls.
Security key (FIDO2)
FIDO is a shorthand of Fast Identity Online, which is an alliance with a goal to reduce our reliance of passwords and it promotes open authentication standards. FIDO2 standard embodies the web authentication standard (WebAuthn). Web authentication promotes authentication via public key cryptography instead of password. The Web Authentication API specification is written by FIDO and W3C (World Wide Web Consortium) and includes collaboration of Microsoft, Google, Yubico, Mozilla and others. A typical security key is a USB or a NFC key. Some vendors have biometric keys also available. Yubico, Thales and Feitian are amongst the well-known companies that develop security keys and devices that utilize FIDO2 and other open authentication standards for passwordless authentication. All three are also part of Microsoft Intelligent Security Association (MISA).
FIDO2 keys have higher level of security as they don’t expose shared secrets and, unlike passwords, cannot be guessed. You probably already guessed that FIDO2 security keys are phishing-resistant. You can authenticate to Microsoft Entra ID or to Entra-joined Windows device using FIDO2 keys. In order to use FIDO2 key as first factor authentication or as a second factor authentication (MFA), your organization’s administrator needs to enable them. After enablement, a user can register FIDO2 security key by going to https://aka.ms/mysecurityinfo.
OATH tokens
OATH is an open standard that defines how one-time password (OTP) codes are generated. Typically OTP’s are valid for a given time, usually 30 seconds, making them time-based one-time passwords (TOTP). Generating of OATH tokens can be done using either hardware or software.
The obvious example of a software OATH generator application is Microsoft Authenticator app which generates OATH codes that we already introduced earlier in this blog as ‘Microsoft Authenticator app verification codes’. Other authenticator applications can be used as well to generate software OATH tokens. Software tokens can be used even when the device connectivity is limited or lost, meaning that the calculation and validation of tokens is not reliant on the mobile data connectivity.
The use of hardware tokens require at least Microsoft Entra ID P1 user licensing. Hardware tokens are on preview at the time of writing (Feb 2024). Organization can choose to purchase hardware tokens from a list of vendors. Hardware tokens supported by Microsoft Entra ID use OATH-TOPT SHA-1 tokens that refresh every 30 or 60 seconds. Implementation of hardware tokens takes significantly more effort compared to software tokens.
Windows Hello for Business
Windows Hello for Business, abbreviated to ‘WHFB’ or ‘WHfB’, is a passwordless authentication option for Windows PCs. The use of this authentication method requires a Trusted Platform Module (TPM) that is a tamper-resistant hardware chip (a crypto-processor) that performs security-related functions. When WHfB is enabled users are able to authenticate to Windows PC with their Microsoft Entra ID account using biometric or PIN that is directly tied to the underlying hardware (PC). Windows Hello for Business has multiple deployment options and can be managed with Group Policies or Intune. It integrates to Conditional Access policies via the Authentication Strength (see picture under the Certificate-based authentication). Depending on the deployment type the device utilizing WHfB has to be Entra joined, Active Directory domain joined or Entra hybrid joined.
Certificate-based authentication (CBA)
Certificate-based authentication is a free feature of Microsoft Entra ID and is in fact phishing-resistant. Users can authenticate to Microsoft Entra ID using X.509 certificates. The use of X.509 certificates requires Public Key Infrastructure (PKI). There’s no requirement to have AD FS infrastructure for CBA. With Microsoft Entra ID Authentication strengths organizations can enforce, allow and require the use of Certificate-based authentication, either via built-in or custom Authentication Strength. Organization can configure and decide certificates to be either single-factor or multi-factor. With single-factor, users are able to sign-in without entering password, but they will need to complete the second factor after successful certificate-based authentication.
Voice call
Voice call of any type can only be used as a second factor. There are two distinct variations of voice calls and depending on what documentation, blog post or portal you’re looking at the terminology might differ because of legacy terminology that’s still around. The two options are ‘Mobile phone verification’ and ‘Office phone verification’. In the unified authentication method management these both are under the ‘Voice call’ method option. Something to know is that the Mobile phone verification is always enabled when the Voice call method itself is enabled. Office phone verification needs to be enabled from the Configure tab separately. Voice call experience is not consistent between countries as the calling number is not guaranteed to be the same.
If you’re using voice calls as second-factor authentication, I would recommend starting to explore other methods as second-factor and plan for migration and user communication. There are better and more secure alternatives available that are even more user friendly than voice calls. I’m quoting a blog title from Alex Weinert, VP Director of Identity Security at Microsoft, from 2020: “It’s Time to Hang Up on Phone Transports for Authentication“
Text messages
Text message channel is typically SMS, but it could also be either Rich Communication Services (RCS) or WhatsApp. I must admit this was new information to me when I wrote this blog. RCS is a communication protocol that is designed to replace SMS and MMS messaging standards on mobile-carrier based text messaging. RCS can use LTE, 5G or Wi-Fi for data transmitting and depending on implementation allows for end-to-end encryption. Android users can already benefit from RCS protocol and Apple has announced that they intend to add RCS support on iOS during 2024. This is good development and might improve the reputation of text message based second factor authentication. Before adoption of RCS protocol into iOS devices my recommendation is still to start planning other better and more secure authentication methods. Even if RCS protocol will be adopted by Apple, it is not totally phishing-resistant which tilts my recommendation to move away from it. For organizations currently using SMS-based authentication, the RCS support for both Android and iOS will improve security in a long run.
Security questions
I don’t really want to go here. I hope that you don’t want to go here either. Microsoft is also deprecating security questions by 2025 and so should the rest of the world. EDIT: No, I was wrong. I read the documentation again, this time more carefully, and I must say I’m bit disappointed that Microsoft did not take this opportunity to retire Security Questions once and for all. Microsoft will make security questions available as method in the unified management later.** If you’re old enough to remember when security questions we’re one of the primary methods for identifying a user with username during a password reset, you know how bad it was and what risks it has now, given how generously people announce everything happening in their lives in social media. And if you’re young enough to not remember, I’m simply just saying that this is something to avoid, don’t accept security questions anywhere as a user or as an administrator. For those using Security Questions, you should seriously consider not migrating them at all and instead retire this SSPR authentication method for good.
I’ll just say that if your still using legacy SSPR controls then you have one checkbox that enables/disables security questions.*
* Seriously, if your organization is using security questions for SSPR then make sure you’ve enabled more methods for users to use as second factor in SSPR. Plan communication, timeline and schedule the deprecation date for security questions method. During transition keep close attention of users that only have security questions as their only method for password reset and gently remind them to register additional methods. Monitoring of user registration status can be done from Protection > Authentication methods > Monitoring > User registration details. Make sure all users have other methods registered before removing the option to use security questions.
** You can complete the migration while leaving Security Questions enabled in the legacy SSPR control pane. Record the Security Questions for later use and complete the migration once Microsoft announces that they’ve added Security Questions to unified management.
Email OTP
This method is used only in SSPR and specifically for password reset, not password change. A code is sent to user’s email which is then used to authenticate and enables the recovery of their account access. This method seems to be enabled by default in Microsoft Entra tenants in the unified authentication method management, but it can be disabled. I’m not fan of using email for sending OTP codes for multiple reasons, but mainly I wouldn’t want to train my users to expect that random codes sent to your email are to be trusted as I could see how this sets the stage for a wonderful phishing scenario that the adversary can abuse. Again, use only if necessary, but seek to replace email with more secure channels and methods.
Temporary Access Pass
Temporary Access Pass (TAP) has multiple use cases. It can be used to bootstrap new passwordless authentication methods like Microsoft Authenticator Phone Sign-in, Windows Hello for Business or Security keys. Instead of using an existing MFA method that might be unavailable to you (forgot your phone at home etc.), administrator can assign temporary access pass to you that you can use. TAP can also be used to replace strong second factor authentication in an account recovery scenario. Think like lost or broken security key or stolen phone that had your registered Microsoft Authenticator app in it. You can also use TAP during the device domain-join setup process.
TAP is a bit of an amoeba. Depending on what the user needs to do, in some scenarios it can satisfy first factor (user not needing to input password) or be used to satisfy second factor. It can even be used by guests during sign-in into the resource tenant (the tenant where your account is of type ‘Guest’).
TAP is time-limited passcode that an administrator can configure in couple of ways. Admin has the options to configure minimum and maximum lifetime.
- Minimum lifetime ranging from 10 minutes to 30 days
- Maximum lifetime ranging from 10 minutes to 30 days
Of course, configuration has to make sense and one cannot configure the minimum to be more than maximum. Admin has a binary option to enable or disable ‘one-time use’. TAPs that are not just for one-time use have validity within the limits of the configured lifetime. The last admin option is about the length of the TAP.
- Minimum length: 8 characters
- Maximum length: 48 characters
I can see valid use cases for Temporary Access Pass especially in situations where user needs to replace the existing second factor temporarily or an organization adopting the use of TAP as part of the new employee setting up their new device for the first time. But two obvious things need to be pointed out here: as the name says, it’s TEMPORARY access pass. Don’t try and replace all other MFA methods with TAP by issuing 30 day long TAPs to users every month. Also as just mentioned, this is not a self-service feature. Administrator involvement is a must as the users cannot summon the TAPs by themselves.
Authentication Strengths vs Authentication Contexts in Entra ID
Authentication Strengths
Authentication strengths are essential part of hardening authentication security and tailoring authentication requirements for specifically targeted users. The concept is very simple and straightforward and only includes a name of the authentication strengths and a list of included authentication methods. An administrator can create custom authentication strengths and for example enforce a specific authentication method upon targeted users. Authentication strengths are used in Conditional Access policies in Access control > Grant section. This ties the requirement (authentication strengths) to the sign-in event (via the Conditional Access policy). An organization would want to use authentication strength to get better control of the authentication methods that are required during the sign-in process.
Authentication Contexts
Authentication context is even more simple concept. All you need to configure initially is a name and a description. You should of course have an idea where you’d like to use the context. Example scenario here is that when elevating an Entra ID role via PIM we would like to require additional (so called ‘step-up’) second factor authentication. Initially and ideally, the user has already satisfied MFA requirement during the sign-in to Azure portal. In our scenario the user has used Microsoft Authenticator push notification for MFA, but if we require a different method (e.g. Security key) then the existing MFA claim does not satisfy and there will be additional prompt for user to complete second factor.
In order to accomplish this, you need to
- Set up authentication context
- Modify Entra ID role to require authentication context on activation
- Set up conditional access that targets (or triggers from) the authentication context
In our example we used authentication strengths and authentication contexts together to achieve our goal. This isn’t a must, you can use them separately also. I recommend using at least authentication strengths to harden authentication requirements that target privileged accounts or otherwise VIP users that have access to highly sensitive data or business critical apps.
Why go passwordless?
The problem with password is that, in many cases, it needs to travel over the network and the service also needs to know it in order to validate that it is in fact the right password. So your password can get compromised if you handle it negligently. But it can get compromised also if the service, an identity provider, that also keeps a copy of your password gets breached.
Modern password management includes hashing, salting and the network traffic might be encrypted. So it’s not like your sending your clear text password over the wire. But they have other weaknesses too. In order to make password as safe as you can you need to require a good level of complexity and some length too. So much length that it might be very difficult for a human to remember it, unless you make it less complex. Why do we have to periodically change our passwords? Well, I guess the use of passwords is inherently so insecure that they are easily compromised. We don’t need to change our Security keys every 90 days or get new fingerprints. Passwords are not based on cryptography which ultimately makes them always less secure than passwordless solutions.
- The obvious benefit of passwordless authentication is that it’s damn convenient and user friendly. I use passwordless methods myself and as a user I’m very happy to use them. I don’t miss typing passwords at all, I wonder who does?
- Passwordless methods are based on more secure technology. WHfB uses the TPM chip and cryptography for signing data. Security keys use public key cryptography techniques. Certificate-Based Authentication uses public key cryptography techniques. See a pattern?
- By shifting to passwordless methods you reduce the service desk load that is related to resetting, managing, rotating and issuing passwords. I would like to say that you can save license expenses when you don’t need to buy password manager software to employees, but Microsoft work accounts cannot yet go completely password-free (meaning that there would not even be an issued password to that account).
- You avoid all the password attack variations from password spray attacks to keylogger attacks to credential stuffing.
Summary
We first went through the available authentication methods and some of their features, use cases and limitations. We then introduced two concepts that are closely related to the authentication methods and some relevant use cases for them. In the end we argued for the passwordless authentication and reasoned why should we transition to use it. As a short summary, passwordless authentication is stronger then traditional password authentication and it cannot be overlooked anymore. It reduces the risk of identity compromise and improves user satisfaction. The latter is actually your best selling point when you’re introducing the change in your organization and we all know that any change in work environment will gather some resistance; more or less.
Stay secure!
