Safeguarding Microsoft Entra ID with passwordless authentication methods – Part 3: Plan, adopt and awareness

This is part 3 of 4 part series. If you haven’t read previous parts of the blog series, I suggest reading them 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. This is the third part of series. Let’s start!

Setting the goal

In this post we will learn about the pros of passwordless and why they are superior to passwords. We’ll dive into how the passwordless authentication works under the hood in a way that a common man should also understand how it works. Then we’ll move on to list some steps for adopting passwordless strategy and selling the passwordless journey in our organizational users.

Benefits of passwordless authentication and cons of passwords

Let’s dig in to the rationale of passwordless once more. I can repeat the passwordless mantra over and over, but I want to you, the reader, to understand why this is a the next evolution from username/password combination. Let’s start by looking at the username/password and why we need to move on from it.

Cons of Passwords

1. Passwords are essentially shared secrets. You know your password, but so does the identity provider. This already creates a problem as you cannot control what the service provider does.
   
2. Passwords need to travel over the network. In order to check if the password is correct it needs to travel over the network. Encrypted sure, at least sometimes, but this still exposes the password and provides an opportunity to the adversary to listen on the traffic.
   
3. Passwords can be guessed. Making matters even worse, password reuse is a legitimate thing. Think of a employee that registers an account to website that sells used items. This account has a password (weak or strong: does not matter) that is actually the same as the employee’s work account password. Website’s security gets compromised and attackers have the access to the accounts and passwords. Attackers can now attempt password spraying, meaning that they will attempt to login to other accounts with that same password.
   
4. Passwords need to be managed, reset and remembered. If not remembered, than you have to have a password manager that stores the password for you. Many of these are cloud services and many of them have also been compromised. Password support, resetting and maintenance, is often also a cost to IT departments.
   
5. Passwords are not bound to anything. It’s just a string. If I know your username (which is not that hard to even guess in the enterprise and work context) and look over your shoulder and see what you’re typing, I can steal your password and use it from my computer later on to login. We’ve found an external solution for this which is called multi-factor authentication. So MFA is essentially just trying to patch the shortcomings of passwords.
   
6. Passwords are susceptible to phishing. Due to the fact that passwords are not bound to any specific thing like a device, they are more vulnerable to phishing and thus to Adversary-in-The-Middle (AiTM) attacks. And because passwords are less secure than passwordless authentication methods, they are also the most commonly phished credentials. Sophisticated phishing attacks allow the attacker to gain access to your password without you knowing or suspecting anything.
   
7. Passwords need to be changed. Or do they? IT industry has adopted periodic password rotation and this habit sits extremely tight. Microsoft’s recommendation is to stop requiring periodic changes as they won’t actually meaningfully increase the security of those passwords. Show me a user who loves to change their password every 90 or 30 days. We all hate it! Even the ones that are security-aware. This also goes back to the password reuse, as we try our best to change the old password as little as possible, essentially reusing the old one as much as possible, making the password easier to guess and not making the password any more secure than it already was to begin with.
   
8. Passwords are tedious. Who else hates typing passwords tens of times during the day? And we all get them wrong from time to time: let me introduce you to the TYPO! Or maybe you have a workaround to this like Notepad or Sticky Notes where you’ve stored your password in clear text form where it is easily copied from, because the password managed keeps auto-locking after few minutes of last activity.
   
9. Passwords were not meant to stand against modern-day attacks. Have you ever stopped and wondered where this all started? There must have been a time when someone saw a need to identify a user on a network and thought that username would be a good solution. Until they realized that username is not enough, they would also need something that only the user and the restricted resource server would know: a password known by the user and the server/application. So maybe, just maybe, passwords were primarily a way for an application to identify a particular user. Not specifically to keep the user account secure against attacks. Making the password more complex, adding more length to it worked for a while and gave us bit more time. But not anymore.

Pros of Passwordless

1. Passwordless authentication is more convenient. Not having to type passwords is convenient. With passwordless we can unlock the game called: Biometrics. It’s convenient not having to remember or find the password. Just be you and use fingerprint scanner or facial recognition or even iris scanner. If you’re work environment does not allow smart phones you can use passkeys (security keys) that are easy to use and lightweight, making them even more portable option to smart phone.
   
2. Passwordless authentication helps to adopt Zero Trust. All the Zero Trust frameworks that I’ve read encourage the adoption and use of passwordless methods. Zero Trust tells us to verify explicitly and at the same time I would argue that typing passwords all the time everywhere increases the risk of compromised passwords and cyber breach. Passwordless methods can alleviate the user friction while also driving up confidence of the authentication security.
   
3. Passwordless authentication can speed up sign-in. This one is pretty obvious but, passwordless methods enable faster sign-in times and more user-friendly. Most smart phones have facial recognition or fingerprint reader and we all use them because they’re faster than typing in codes or passwords. According to Microsoft ¹ “…the average user spends more than 12.6 minutes each week entering or resetting passwords”. If you multiply the average time with a number of employees in your organization and again multiply with 52 weeks in a year (minus the holiday weeks that depend on national regulations), you get the total time it takes on average in your organization for users to manage, reset and type in their passwords. The number might surprise you. In the same blog post Microsoft states that Windows Hello is three times (3x) faster than traditional password.
   
4. Passwordless authentication cannot be guessed. Cryptographic keys cannot be guessed. And when you’re using passwordless authentication, there’s nothing that you need to hide from prying eyes as they cannot replace you in biometric authentication or provide the cryptographic keys that are bound to your device. Also most biometric systems are equipped with liveness detection so that the presented biometric cannot be faked.
   
5. Passwordless authentication is highly secure. Passwordless gives us the option to use open standard-based options like FIDO2 which is vendor-agnostic and WebAuthn that is also an open standard for authenticating users on web applications by asking for FIDO2 credentials. Biometric authentication is used to access a locally stored cryptographic key. The process for unlocking the cryptographic operations of security hardware (like TPM chip) using biometric templates is actually highly secure and inherently multifactor. When deploying passwordless method like FIDO2 or Windows Hello, a biometric template that the user generates by their fingerprint, PIN, gestures or facial features, is used to generate a cryptographic keypair on that device. Further authentication request are signed using that private key only if the same biometric template is provided making the biometric authentication as secure as it gets. As the credentials are bound to the device’s security hardware, the attacker would have to steal the device first and then try to spoof the biometric. And by the time that will happen, you’ve already had a chance to revoked the trust in the stolen device.
   
6. Passwordless authentication stores secrets and keys locally. As outlined in previous benefit, the idea of passwordless is that you register a device to your account that stores cryptographic keys that you can access with biometric or PIN which are used to sign cryptographic operations that prove you are you. An actual secret or key is not sent over the network to be validated. And just like that we have eliminated one attack vector completely.
   
7. Passwordless authentication includes phishing-resistant methods. And these methods are a golden standard for modern secure strong authentication. At the time of writing these methods are FIDO2-based security keys (passkeys), Windows Hello for Business and Certificate-Based Authentication (CBA).

How does passwordless authentication work?

Passwordless authentication is what is sounds like; authentication without the password. Typically passwordless methods can be categorized in the following ways:

• Possession factors like OATH tokens (software/hardware), TOTPs and such
• Biometric factors like facial recognition, fingerprint or retina scanners, gestures, voice or even combinations of these
• Magic links or One-time links (OTL) that are sent to users email and access granted by clicking the link

Note! I want to say that I don’t like or prefer the use of Magic links. Firstly as users’ commercial mailboxes are typically poorly secured making them easily breached. Secondly because it teaches users to click links that come to your mailbox and makes it tempting for attackers to try and spoof those sites and to send their own malicious phishing links.

Most passwordless methods are based on public key cryptography. This blog post is not going to cover public key cryptography in detail.

I think it’s somewhat important to understand how passwordless authentication and especially how CTAP2/WebAuthn authentication works. I’ll try to explain:

FIDO2 passkeys are able to make complex mathematical calculations to generate cryptographic keys. When user registers the passkey to a service, the service will remember the key and key will remember the service’s domain. For that domain the passkey will generate private and public key and the public key will be also given to the service. When user wants to authenticate to the service, the service will generate a nonce (an arbitrary number) and send it to the user which encrypts it using the private key that matches the domain of the service. The signed nonce is sent back and the service will use the public key to decrypt the nonce and compare it to the nonce it sent. If the nonces match, the user must be who they claim to be as the nonce was signed using the private key pair that matches the public key. This entry in the passkey only works to the domain it stored. If you want to use the passkey to authenticate to a different service, you need to go through the registration flow again, which will make another entry to the key with (at least) another domain and new public and private key pair. This way every service will have unique key pairs on your passkey.

On a high-level

Here are the phases of passkey usage where the first step very broadly covers the whole registration process and subsequent steps cover the actual authentication

1. User registers passkey to the service
   • Passkey stores: service’s domain, user ID (e.g. UPN), public and private key
   • Service stores: user ID and public key
2. During user authentication user first inputs the user ID (which is typically UPN).
3. Service will generate a unique nonce, store it with the user ID and send the nonce to the user in a https request
4. User’s passkey will check the request’s domain, find a matching domain, sign the nonce with the private key and send it back while also requesting a primary refresh token (PRT)
5. Service will receive the signed nonce and use the public key to check if the nonces match
6. Upon matching the nonces, the service sends user a token and the user has been authenticated
7. If the nonces does not match, the authentication fails.

The reason for not matching would be that the nonce would have been signed using different private key then what matches the legitimate and expected public key. Therefore the nonce has been signed by someone else then the expected user. More details and diagrams of FIDO’s CTAP2 authentication (Client to Authenticator Protocol 2) and W3C’s WebAuthn (Web Authentication) protocols can be found from Ping Identity, Yubico, FIDO Alliance, W3C, DUO Security and similar vendor’s and organization’s websites.

Most modern passkeys have liveness detection. They usually require you to touch them upon the authentication. Touching them generates a random string that is different with each touch. Some passkeys also have biometric fingerprint scanner included. The biometric features of a user are generally speaking unique. Devices with biometric, the biometric template is stored in the devices security hardware and is compared to the biometric features of a live human. Upon successful match the access to the cryptographic keys is then granted and the passkey or other device can go ahead and sign the nonce. The biometric data is not sent over the wire and not stored by the service provider nor the hardware provider. If you have a smart phone and tablet you’ve probably noticed that you had to scan your face separately with both devices to enable face id.

How to adopt passwordless strategy?

First, we want to familiarize ourselves with the passwordless authentication methods and make a decision which methods we want to use in our organization. Using the passwordless wizard is a good starting point: https://aka.ms/passwordlesswizard. Reading this three part blog series is another. You have to understand your device landscape and user personas. When you know what type of devices you have and how users are using them (at the office vs. on the road/construction site/cargo ship etc.) you can map what passwordless methods are viable for you. As a first measure, our identities should reside in Entra ID. If they’re not, we should plan hybrid identity strategy first and deploy Entra Connect or Cloud Sync services.

You should have a plan what the change is going to look like in your organization. Along with the usual project management ask yourself these specific questions:

• Do I know my organization’s registered methods and most used methods at the moment?
• What type of passwordless capabilities will your organization support? Platform (WHfB), software (MS Authenticator app), hardware (FIDO2 passkeys) or combination?
• Do I need Temporary Access Pass to let new users to register passwordless methods?
• Are there deployment prerequisites that we do not yet meet that would affect the cost of deployment? For example
• Do certain user personas have mobility requirements? For example, this could maybe rule out Windows Hello for Business and make FIDO2 passkeys more attractive choice.
• Do certain user personas have security requirements? For example, this could maybe rule out non-phishing-resistant passwordless methods (Microsoft Authenticator app).
• Who belong to the user pilot group? Who are pro-passwordless users that can advocate the change?
• Do we have a process and tools to revoke trusted authentication methods if devices or passkeys are stolen?
• Do I need rollout and adoption milestones? For example, in bigger organization these milestones make sense.
• Do I need to change Conditional Access policies? Do I need new authentication strengths?
• Does my organization use AD FS and how does it affect my user experience?
• Can my users register mobile devices if they want to adopt passwordless phone sign-in?
• Is my organization supporting Windows sing-in with FIDO2 passkeys?
• What reporting does my organization need during project and after project?

Some answers will uncover themselves by using the passwordless wizard.

When you have a high-level project plan ready, you should start with the most time consuming task which is user communication and awareness. Like any user base, yours’ too have people that have never heard passwordless or are resisting technical changes because it’s only two years until their retirement or whatever the reason might be. There are templates for communicating these changes at https://aka.ms/MFAtemplates. Start communicating as soon as possible to allow yourself and the users time to understand the change. Some users are bound to ignore the communication, so don’t aim for perfection, aim for majority. You’re first communication doesn’t have to be detailed information about methods and dates, it can be more strategic communication that explains why the change is necessary and how it will protect company’s business in the long run. As the project goes further the level of details to the user get bit deeper.

If your budget allows it, organization wide awareness campaign would be wonderful! If you can get a high profile sponsor from top management team to be an advocate for passwordless, that would be really valuable also! Awareness and communication takes time, more then we usually anticipate. Old habits die hard etc. Because users and their daily working habits are involved in the change, it’s crucial to count enough time for users that are slower to adopt changes and for users that are trying to resist the change. The user mindset change here is from familiar and conventional to modern but unknown. Also don’t make the adoption schedule too hasty, take your time, every organization is different.

Start adoption with pilot users and make sure to listen feedback. If there are issues, take your time to resolve them here before expanding for more users. For each group you’re bringing into the passwordless deployment project make sure they…

• Can register new authentication method
• Can use newly registered authentication method during login
• Can remove authentication method
• Understand the process for stolen or lost device

Remember continuous communication to users also during the project. Once users have successfully registered new passwordless methods and are familiar with them, you can start rolling out system-preferred multi-factor authentication (not covered in this blog post) to enforce the most secure method by a user during login. Last step should be requiring passwordless method via conditional access policy and authentication strengths. Slowly but surely your getting to your goal of reducing password authentication.

How to sell the passwordless change to users?

We’ll start with the ease-of-use as passwordless methods are more intuitive and don’t rely on user’s typing skills, memory or require to open password manager software which most likely than not also requires a password to open. We’re all so accustomed to use our mobile devices and passkeys are so effortless that it’s hard for me to imagine a user that would go back to passwords after trying out passwordless.

We could also argue that the users don’t have to worry anymore about managing password, resetting them or being worried about losing or forgetting their password during vacation or leave. In a side sentence we can also mention that passwordless is more secure then passwords. It’s not really something all users give a damn, but some users do. A nice bonus is that every passwordless user is one user less calling for service desk to help them with a password reset.

Some users might be worried that they will “mess up” and get phished by clicking the wrong link in an email. We’ll depending on the passwordless method, we can assure the users that this won’t happen anymore. They should remain alert and avoid clicking suspicious links, but if they do, the phishing-resistant passwordless method will not work on a spoofed lookalike domain.

One clever tactic, and this is true for any change, is to select few sympathetic pilot users who are pro-change (pro-passwordless in our case). Once they’re onboarded into passwordless they will naturally act as advocates for the passwordless methods and if we’re lucky enough, other users might feel envious that those VIP users have something cool and shiny that they don’t have.

Summary

In this post we have gone over why passwordless is superior and most secure way to authenticate, how you can make an argument for passwordless and against traditional passwords and how it all works under the hood. We’ve learned how to plan, adopt and embark passwordless journey with pro-passwordless pilot users. Adoption of any change is the hardest part. Every user will try to understand if the change is good or bad for them. If it’s not good, or it is laborious to adopt for a user, you’re going to experience some pretty heavy headwind.

Honestly I don’t really get the excuses that organizations could not start adopting passwordless as there are some legacy apps that don’t support passwordless. Passwordless journey does not have to be all or nothing game. If you have identities synced to Microsoft Entra ID and you have users using Microsoft 365 apps or other SaaS apps that trust your work identities you have soldi base to start working with. At minimum you should plan to secure your most impactful users with passwordless.

In the next part we will see how to enable passwordless methods.

Stay secure!

References

1. 10 Reasons to Love Passwordless #4: Secure your digital estate, while securing your bottom line – Microsoft Community Hub ↩︎