MFA - Why should I use it?

Surely by now everyone has turned on Multi-Factor Authentication (MFA) as part of their identity protection strategy. Not necessarily - I regularly come across people who have not enabled this crucial feature, usually through the company/institution's management thinking it is not necessary or not worth the hassle. Usually this is followed up with a compromised account sending thousands of emails in an attempt to gather credentials from contacts of the compromised user.

I've previously written about Azure Conditional Access and MFA, this post is a more general look at MFA and also covers some of the new Azure MFA features.

What is MFA?

Put simply, MFA is an authentication method that requires multiple factors to login. Think of a traditional password as a single factor, and things like biometrics, single-use codes and apps as additional factors. At its simplest MFA means "password plus one of these additional factors", however in some cases you can define how many factors you will require.

The core categories for this are:

• Something you know such as a password, or security questions
• Something you are such as biometrics (touch ID, facial ID)
• Something you have such as a mobile app, or a physical hardware device (token) for generating codes, or a phone to receive a SMS code
  

Why use MFA?

A recent UK government survey shows that 83% of cyber security attacks occur through phishing. The key reason for using MFA is that a username and password is no longer sufficient to log into a service. It doesn't matter if your users have been tricked into giving credentials via phishing, or whether they have re-used credentials elsewhere and that site has had its data stolen - the attacker will not be able to log in.

In the connected world, especially with the recent trent for remote working, company data is increasingly available from outside the traditional physical network. This obviously increases its exposure to attack, something which can be protected against by enforcing MFA on your user accounts.

Besides the potential leaking of company data - which could include valuable intellectual property - the traditional e-mail phish which spreads by sending more e-mails from the compromised account will have a negative impact on the company's public image and reputation.

Azure MFA

App-based MFA usually consists of a 6 digit code per account which is re-generated every 30 seconds. With Azure MFA and the Microsoft Authenticator app, you can also use push notifications. With a push notification, when you attempt to authenticate your authenticator app will pop up with a prompt, traditionally this would contain the options Approve or Deny. While this is easier for the user than having to type in a 6 digit code, it does have some disadvantages. If a user is prompted repeatedly in this way, they will become accustomed to just pressing Approve, potentially even when they are not attempting to log in. This defeats the purpose of the system, if an attacker can enter the correct username/password, cause the prompt to appear on the user's phone and have it approved anyway.

There are two new features which improves this process, both currently in preview:

• Use additional context in Authenticator MFA notification will show additional details in Authenticator, such as a map showing the location of the device attempting to authenticate, and details such as the App Name. This is great if users pay enough attention, however those who have "click fatigue" may still just press Allow whenever it pops up, even if they are not attempting to authenticate at that time.
• Use number matching in Authenticator MFA notification will show a 2 digit number on the login prompt, which the user is then prompted to enter into the authenticator app notification. This way, if the user is not attempting authentication then they will not have the 2 digit code required to approve the request, a much better solution.
  

These two features can be combined, to show the map and app name alongside requiring number matching. Both of these are currently in preview and are therefore disabled on tenants; they can be enabled through the following process:

• Open the Azure Portal > Azure Active Directory > Security > Authentication Methods and select Microsoft Authenticator.
• Enable this method, if not currently enabled, and configure the scope - I strongly recommend using the default All Users. Now click on the menu button, and then Configure.
  

  

• Select the Authentication Mode (Any, Passwordless or Push) - again recommending the default here, which is Any, and then configure both number matching and additional context. The default setting for these is Microsoft managed, which basically means it should be enabled when the feature has been fully released. To turn them on early, select Enabled.
  

  

  
  

If these settings are left as Microsoft managed, they will be enabled within a few months of the feature reaching General Availability (GA).

As is usual with IP geo-location, it's not perfect - I'm a few hundred miles away from London - but at the very least the country should be correct.

Protecting MFA signup process

Enabling MFA and directing users to set up MFA at next logon is only the first step. What if the next person to log on to an account is an attacker, using compromised credentials? They would then be directed to complete MFA sign up and they will do so - tying their own device or, more likely, software based app to the account. They can then log in satisfying the MFA requirements and carry on with their attack.

With Azure, we can use Conditional Access to prevent this. I covered this scenario previously in my Conditional Access and MFA post but essentially you are creating a Conditional Access rule to only permit MFA setup from a trusted location, such as your on-premises public IP range - requiring the person completing MFA setup to be physically on site (or using a VPN). Other requirements you could set as well, or instead, of the location are that the device must be hybrid Azure AD joined, or enrolled in Intune and compliant. This would allow signup from off site if using a corporate device.

Further Reading

• Azure - Conditional Access and MFA
• Use number matching in MFA notification (preview) - Microsoft Docs
• Use additional context in MFA notification (preview) - Microsoft Docs