Skip to content

Hack Your Security with One Trick: Strong Authentication

Did you know that not all MFA methods are equally secure? In this post, I will explore why switching to a strong authentication MFA that can also serve as a passwordless logon is crucial. Don’t miss out on upgrading your security and protecting yourself from phishing attacks.

Table of Contents

Background

We have emphasized the significance of using MFA to safeguard user accounts for a while now. MFA is a powerful tool that can prevent up to 99.9% of attacks on our accounts. In today’s remote workplace, where identity is the new security perimeter, it is crucial to take steps to protect our identities. While our ultimate goal is to have a passwordless sign-in method, we currently have various MFA options available that can help keep our accounts secure.

Strong Authentication
Authentication Methods available in Azure Active Directory (graphics by Microsoft)

The further to the right we move in the table above, the more secure we stay.

The Terrible Password

As the picture above states, using passwords alone is a bad solution. Passwords alone make it easy for cybercriminals to harm us. If our passwords are too simple, short, or standard, it’s straightforward for hackers to crack them using readily available tools.

The only people that love passwords are hackers. Because they are hard for humans to remember and they are easy for hackers to get. 81% of successful cyberattacks are due to a compromised username and password, according to Verizon Data Breach Investigation Report.

Shockingly, a password with fewer than eight characters can be hacked within seconds. Attackers can also easily phish your credentials by fooling you into logging in to a fake page and stealing your password. Username and password combinations are traded on the dark web, and you can check if your identity has been part of known password databases by searching https://haveibeenpwned.com/.

Cybercriminals don’t break into your systems – they log in!

The Simplest MFA Methods by SMS

Any MFA is better than no MFA! But still, we should stop using SMS and voice calls as MFA methods since these have known weaknesses.

SMS codes are visible on the locked screen. Could the username and password be in the notes on the desk?

For more details regarding this, please see https://http://aka.ms/hangup.

The Better Way of MFA Through Authenticator

Moving from old-fashioned SMS and voice calls to more secure push notifications in Microsoft Authenticator.

Microsoft Authenticator is also a more secure solution with higher usability and availability. The Authenticator will also be enriched with number matching, information about the application that requests the approval, and the location of the IP address the sign-in originated from.

Number matching on the phone with info on the app and location before fingerprint is required.

This will raise the security even more and address MFA fatigue attacks where users unreservedly approve MFA requests.

The Superior Passwordless Solution

Some users find it frustrating to have the extra security layer of MFA on top of remembering their passwords. That’s where passwordless authentication comes in! This way, users don’t have passwords that cunning criminals hunt for.

With this method, you can bid farewell to password hassles and enjoy more convenient authentication that requires something you have, are, or know.

Something you haveSomething you are Something you know
Windows DeviceFacial RecognitionPIN
PhoneFingerprint
Security Key

Today there are three options for passwordless authentication giving the highest security with added convenience.

Microsoft AuthenticatorWindows Hello for BusinessFIDO 2 Security Keys
Microsoft Authenticator is a mobile app that provides two-factor authentication and passwordless login for Microsoft accounts and other services.Windows Hello for Business is Ideal for information workers with their dedicated Windows PC. Biometrics and PIN are tied to the PC, making it secure and convenient.FIDO2 security keys provide strong authentication and passwordless login combined with biometrics or PINs, reducing the risk of phishing and credential theft.

The Administrator of the Tenant enables passwordless authentication methods. While looking into this, I recommend migrating to the new Authentication Methods Policies. This is well documented by Maurice Daly, Jan Ketil Skanke, and Michael Mardahl in the MSEndpointMgr post: Migrating to Authentication Methods Policies – Happy days!

Deploying Windows Hello for Business for all users in the organization is an excellent place to start. This is the most convenient and secure way to authenticate users. Sandy Zeng, Ben Whitmore, and Michael Mardahl have great posts on this topic at MSEndpointMgr.

Sensitive and privileged accounts and roles should be enforced to use unphishable strong authentication based on FIDO2. I have earlier described one use case using FIDO2 to securely sign in to a Windows device as a privileged account.

Example of two FIDO2 security keys from Feitian (left) and Yubico (right)

You can learn why a strong password and regular MFA aren’t enough by reading this great post by Jan Bakker: How to set up Evilginx to phish Office 365 credentials. After reading this, you should understand why strong authentication is preferable, especially for privileged accounts.

Implement Strong Authentication

With strong authentication, we want to ensure that only authorized users can access Azure resources, minimizing the risk of data breaches or cyber-attacks. The best way of implementing this is by diving into phishing-resistant FIDO2.

FIDO2 keys resist phishing attacks because they do not share secrets with service providers or reveal them to attackers.
FIDO2 keys can be USB, Bluetooth, or NFC devices that require physical presence and a PIN or biometric to unlock.
FIDO2 keysuse public key cryptography and do not reveal secrets, making them resistant to phishing attacks.

Enable FIDO2 Security Key Method in the Tenant

After migrating your tenant to the new authentication methods policies, you are ready to enable FIDO2 security keys as a method in your tenant.

Navigate to the Microsoft Entra Admin Center, Azure Active Directory, Protect & Secure, and Authentication Methods. Click on FIDO2 Security Key under Policies and enable this for all users or groups of users.

With the FIDO2 Security Key enabled, the targeted users should be able to register for the service.

Onboard a FIDO2 key for a user

The FIDO (Fast IDentity Online) Alliance is an organization that supports the development of open authentication standards and aims to decrease the reliance on passwords for authentication purposes. The most recent standard developed by the FIDO Alliance is FIDO2, which includes the web authentication (WebAuthn) standard.

A myriad of FIDO2 security key providers are compatible with the passwordless experience. Eric Woodruff has written a good article on Choosing a FIDO2 Security Key and has a great resource on FIDO2 Key Reviews.

I will use a FEITIAN ePass FIDO2 FIDO U2F USB-C + NFC Security Key (K40) this time.

⚙️USB-C and NFC communication
⚙️Supports hundreds of FIDO U2F/FIDO2 services
⚙️Supports Passwordless on Azure AD and Microsoft Services
⚙️Compliant with GSuite and Google
⚙️Secrets are not shared among service providers.
⚙️No phishing or man-in-the-middle
⚙️Support Android, ChromeOS, Windows, MacOS, Linux
⚙️Plug and Play identified as a USB HID device
⚙️Fits nicely on a key-chain or in a wallet

To add the key as a sign-in method for the user, navigate to mysignins.microsoft.com and add Security Key as a new sign-in method under the Security Info section.

Next, I can select if I will register a USB or NFC security key. My FEITIAN key does support both technologies, and I will continue by selecting USB.

The user will now be led into setting an external security key on the account.

The key should now be presented to the Windows PC to continue adding a PIN code. This will represent “something you have” (the key) combined with “something you know” (the PIN). There are also FIDO keys available supporting “something you are” (fingerprint/biometric).

Next, I need to prove my presence by physically touching the key.

Now the setup is completed, I can give the key a name that will be visible in the portal.

The key is now registered as a sign-in method for the user.

Introducing Strong MFA Methods To The Users

Microsoft has prepared some communication templates you can download and use to introduce the MFA features to the users. There are a lot of templates available at aka.ms/mfatemplates.

Picture by Merill Fernando

The one in the picture above is related to introducing strong auth, available at aka.ms/mfatemplates/strongauth.

Choose FIDO Key to Sign In

When signing in to Microsoft services, the user can use his security key as a sign-in method.

As seen above, the user can sign in with username + password + mfa but chooses to use the key, enters her pin, and touches the key to sign in. I have previously described how you also can enable FIDO2 key sing-in on Windows endpoints through Microsoft Intune.

Force Strong Authentication for Sensitive Operations

So far, I have made it possible for users in the system to use security keys if they want to. As an administrator, I also want to force specific requirements for how users authenticate themselves when accessing certain resources. For instance, I may want to make it mandatory for Global Administrators to use authentication methods resistant to phishing attacks.

As always, MFA is configured using Azure Conditional Access policies. I will use the authentication strength feature to force strong authentication for sensitive resources.

Authentication Strengths

I can find Authentication Strengths in the Microsoft Entra Admin Center under Azure Active Directory, Protect & Secure, and Authentication Methods.

I already have an authentication method covering phishing-resistant MFA. It is possible to add custom authentication strengths as well. This is not necessary for this first purpose.

Conditional Access Policy with Authentication Strength

I can now modify one of my CA policies to require phishing-resistant MFA.

The policy above is now valid for all members of the Admins persona. When trying to sign in to the tenant using username+password+mfa, I receive the following message:

This way, the persona will be forced to use strong authentication.

Add Strong Authentication to PIM

There is possible to get more granular controls by using Azure AD Authentication Context combined with Privileged Identity Management (PIM). This way, I can target the already configured Authentication Method to the PIM elevation operation.

Configure Authentication Context

I find the Authentication Context under Protect & Secure, Conditional Access in the Entra Portal.

This authentication will now be available in Conditional Access policies.

Conditional Access Policy using the Authentication Context

Now I can modify a Conditional Access Policy to utilize the authentication context created above by selecting it under Cloud apps or actions.

With the CA policy, we can tie everything together in a PIM-activated role or group.

PIM with CA authentication context

It is now possible to add the Conditional Access authentication context as a requirement for a given Azure AD Role. This is done in the Entra Admin Center under Azure Active Directory, Identity & Governance, and Privileged Identity Management. Select the role and navigate to Settings, where Azure AD Conditional Access authentication context can be required on activation.

This can be added the same way for Privileged Access Groups.

This will require Strong Auth upon activation of the PIM group.

PIM Requiring Strong Auth

When the user now PIM activates the groups/roles with the Azure AD Conditional Access authentication context requirement, she will be required to do the strong authentication.

This way, we can ensure that users accessing highly sensitive roles or groups use strong authentication.

Force Specific FIDO2 Key Brands

Besides forcing strong authentication, we can also force using given FIDO2 key brands and types. This way, we can control that some operations require FIDO keys with biometrics.

According to the FIDO2 rules, when a security key is being checked, it should have a unique ID called an “Authenticator Attestation GUID” (AAGUID). This ID comprises a set of numbers and letters, and it tells what kind of security key it is, like the brand and model. The AAGUID should be the same for all security keys that the same company makes but different for keys made by other companies. To make sure this happens, the AAGUID is chosen randomly.

I can use the AAGUID of a FIDO2 security key to set up rules for who can and can’t use it. For example, I can only allow specific security keys based on their AAGUID or block particular ones based on their AAGUID.

The AAGUID can be seen in the security method under My Account for users who have added a security key. Here is an example from the FEITIAN K40 used in this demo:

Else, it is not easy to find the AAGUID key. One option is to use the get_info.py script available at python-fido2: library functionality for FIDO 2.0, including communication with a device over USB. (github.com).

Jonas Markström has created a list of FIDO2 AAGUIDs available on GitHub.
Feitian has a list of their AAGUIDs on their website.

FIDO2 Key Restrictions in Authentication Methods

I did configure the FIDO2 Authentication Method earlier. The Methods found under Policies can be further configured to enforce key restrictions.

The setting above will now only allow the Feitian K40 type of FIDO2 keys.

If I add a new Authentication Strength, I can add a list of allowed FIDO2 keys directly to the authentication strength advanced options.

Being creative in this area, I can enforce specific FIDO2 keys to certain access. This can be locked to a given brand of FIDO2 key or forced to use FIDO2 keys with biometrics.

Strong Authentication on Auto

Microsoft has recently released System-prefered multifactor authentication. The feature works by checking the authentication methods registered for the user and prompting them to sign most securely, such as Microsoft Authenticator Push notifications or FIDO2 security keys.

Administrators can enable system-preferred MFA to improve sign-in security and discourage less secure methods like SMS. System-preferred MFA is a Microsoft-managed setting that can be enabled or disabled for all users or a group of users.

Once the feature is enabled, the system will determine and present the most secure MFA method despite the default authentication method defined by the user. Strong Authentication on autopilot!

Feitian Toolbox

This post has been focusing on the FEITIAN FIDO2 keys. They have a tool for managing protocols and functions on the FEITIAN keys. More information on the tool is available here: OTPTool – FIDO Security Keys (ftsafe.com)

There is also a FIDO2 Manager available from www.ftsafe.com. This can be used to manage pins and fingerprints and reset the keys.

Alternatively, Windows native Settings can be used to manage the FIDO2 Security key:

That way, you can natively configure the settings of the FIDO2 security key.

Track The Usage

When moving your users to more secure MFA forms, tracking the usage is a good idea. There are some monitoring tools available for this in Microsoft Entra Admin Center. These are found in the Monitor section under Azure Active Directory, Protect & Secure, and Authentication Methods.

The “User registration details” report seen above will give detailed insights into which users can use MFA and Passwordless and which methods they have registered. Use the filters to smoke out the users with only weak MFA methods registered.

The Activity report will give insights into which authentication methods are used among the tenant’s users.

You will get detailed user information by clicking on a method in the graph above. This way, you can find and follow up on the users utilizing weak methods.

Pay attention to the Usage part of the Activity report, where you can find more information to track down.

Using these reports, you can get a clear view of the status related to active authentication methods.

Track Down the SMS’ers

While the reports above can be used to get insights, you can also use KQL queries for the Log Analytics. The following example will list all users with text messages as their only MFA method:

SigninLogs
| where TimeGenerated > ago(30d)
| where UserType == "Member"
| mv-expand todynamic(AuthenticationDetails)
| extend ['Authentication Method'] = tostring(AuthenticationDetails.authenticationMethod)
| where ['Authentication Method'] !in ("Previously satisfied", "Password", "Other")
| where isnotempty(['Authentication Method'])
| summarize
    ['Distinct MFA Methods Count']=dcount(['Authentication Method']),
    ['MFA Methods']=make_set(['Authentication Method'])
    by UserPrincipalName
//Users with one method only equal to text message
| where ['Distinct MFA Methods Count'] == 1 and ['MFA Methods'] has "text"
Kusto

This will list all users using SMS as their only MFA method.

Track Down the Password’ers

It is also good to find all the users signing in with passwords only.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize ['Single Factor Authentications']=make_set(UserPrincipalName) by AppDisplayName
| extend ['User Count'] = array_length(['Single Factor Authentications'])
| order by ['User Count'] desc
Kusto

The KQL query above will give you a starting point for finding users signing in with usernames and passwords only. If you find Kusto queries to fit your nature, the following GitHub repository contains some excellent queries: Sentinel-Queries/Azure Active Directory at main · reprise99/Sentinel-Queries (github.com)

Wrapping Up

Strong authentication is a crucial way to enhance the security of user accounts and resources in Azure AD. Passwordless methods resistant to phishing and other attacks can reduce the risk of credential theft and account compromise. You can enforce strong authentication for specific scenarios and roles using conditional access policies and PIM.

Strong Authentication
Strong Authentication

You should consider moving your regular users to secure MFA methods such as Microsoft Authenticator and Windows Hello for Business. Your privileged roles and accounts should use strong authentication methods like FIDO2 security keys. This will help protect your organization from common identity attacks and improve the user experience.

Thanks to Della Han at Feitian for providing me with the FEITIAN ePass FIDO2 FIDO U2F USB-C + NFC Security Key (K40) used to write this post!

FEITIAN is offering new Microsoft users a 10% off discount on this page.
At checkout, enter code: MSFT-FTUS-209-10

You should also read my follow-up post: Simon does The Secret Weapon for Strong Authentication: FIDO Keys with Biometrics

Published inAzureEntraIdentitySecurity

5 Comments

  1. Patrick J Patrick J

    Really great sum-up, was a pleasure reading this.
    One thing to mention: The KQL Query listing all users who a re only using password seems to be a bit odd: The query lists all users who are signing in to the windows device via WHFB as “Using only password”. In my opinion the query only lists single factor logins, not single factor logins WITH ONLY password.

    Regards,
    Patrick

Leave a Reply to Michael Pietrzak Cancel reply

Your email address will not be published. Required fields are marked *