What is your excuse for passwords

What is your excuse for passwords and why is it, that we still heavily rely on passwords? Is it because passwords are easier to remember by end-users, or is it that someone thinks that end-users are not capable of handling anything else then a simple password. In other words, do we tend to think of end-users are not ready for passwordless? Is this your excuse for passwords too? Perhaps we (admins) think that going passwordless is difficult and comes with a lot of management, support tickets and sleepless nights? Or is it something else? Think about it… What is your excuse for passwords? If you want to skip to the instruction video directly, then here’s the link: https://youtu.be/zXxOIhspc_c

Strong passwords

Most of us, (I hope) will have some sort of strong password policy in place to block users from using weaker passwords right? And if you’re a little crazy, you’ve forced users to have a almighty 15 character long password, I think you might have found that your end-users are in quite a predicament. Ask yourself this: How can I help end-users with a very strong 15+ character passwords they can never remember? They answer is easy: Don’t require them to remember a password to begin with! It’s that easy. Or is it not?

Beyond passwords

What better way is there to test this theory than showing you how easy it actually is to have users not knowing their passwords, but still be able to authenticate and get their job done. We’re going full passwordless! For this test, I’ll use a couple of user accounts, with random passwords with more than 15 characters. I’ll show you some scenario’s new users have to deal with. For instance, enroll a new Windows 11 device, setup MFA, sign-in using a browser, and how to configure a security key. And all this, without ever knowing the actual password. I’m going to use some of the new Feitian Biopass FIDO2 security keys If you want to have more background information on going passwordless, check out my previous post on eliminating passwords or password freedom.

Feitian Biopass K49 and K50 FIDO2 Security keys

This time, I’m using the brand new Feitian BioPass K49 and K50 FIDO2 Security keys. These 2 keys are the successors of the K26 and K27. Like before, they come with the build-in fingerprint sensor. Have a look at “FEITIAN Technologies Co., Ltd.” for more information.

I’ve used FEITIAN products before and like the K27, the all metal K50 looks great and feels solid. It is a little bigger than the K27 though. The older K27 had a square biometric scanner. Both these new keys have round biometric scanners which feels more natural. The key has a red and a green LED, indicating failed or successful fingerprint verification. Watch the LED when you put your finger on the sensor because if you fail to verify your fingerprint 15 times in a row, the security key gets locked and you’ll have to reset the key. Once reset, all data including your fingerprints and credentials are deleted. For this post, I’ll be using these keys to sign in to my devices, No excuse for passwords!

Passwordless authentication with windows and Azure AD

Passwordless authentication is any form of authentication that doesn’t require the user to provide a password (obviously) to sign-in to a windows device or online services. Microsoft Azure supports the following passwordless options;

• Windows Hello for Business
• The Microsoft Authenticator app
• FIDO2 security keys

I wrote another post on Passwordless authentication with windows 10 and Azure AD so make sure to read that one too, if you’re new to passwordless authentication. In this post I’ll focus on a passwordless demo using FIDO2 security keys and Temporary Access Pass.

Prerequisites

I’m Assuming you’ve read the other blogs I wrote on passwordless. Therefore I’m not going to touch all the prerequisites in this blog.

• Azure AD Multi-Factor Authentication
• Enable Combined security information registration
• Authentication methods configured and targeting user scope in Azure AD
  • Temporary Access Pass (TAP)
  • FIDO2 Security Key
• For this demo: A user account with a random password you and the user do not know
• For this demo: TAP enabled for the user
• For this demo: WHB Configured with Use security keys for sign-in enabled

Enable passwordless authentication with Azure AD

Let’s enable passwordless authentication in Azure AD. Browse to:

Azure AD > Security > Authentication methods

Make sure FIDO2 Security Key and Temporary Access Pass have been configured and target the right user groups. This enables passwordless methods for users.

User account setup

I’ve setup a user account with a random password and configured a Temporary Access Pass as a authentication method. The user is never going to know the original password. Better yet; nobody knows the password. That’s the meaning of passwordless right? Please watch the video to see the whole process in action.

First, add TAP as an authentication method for the test user:

• Click on Add authentication method
• Choose TAP as the preferred method
• Set the activation duration
• Set One-time-use (if set to Yes, the TAP can only be used once)
• Click on Add
• configure Azure TAP

When you click on Add, it will show you the temporary access pass. This is what you need to share with your user.

Note: Before you click on OK make a note of the temporary access pass because after clicking OK, there is no way to show the TAP again. If you did not take a note, you will have to create another TAP.

Since TAP is general available, Microsoft made some changes and I’m happy to read that you can also use TAP while enrolling a device with Autopilot:

I quote: “Users with a Temporary Access Pass can navigate the setup process on Windows 10 and 11 to perform device join operations and configure Windows Hello For Business”

This means, that I can start enrolling my device, and if I’m correct, I can setup Windows Hello for Business, and my security key without a password.

User onboarding process

You will have to think about how you want to onboard your users. Although I didn’t mention this before, it’s essential that you have a good onboarding process. Think about the following steps:

• How do you inform new users about their username and Temporary access pass?
• When do you create a TAP?
• Is it going to be a one time use TAP?
• What is the maximum lifetime of your TAP configuration?
• When and how do you give users their TAP?
• How are devices delivered?
• Do all users need to have a security key?
• Do users need to identify themselves before receiving the TAP/Device/Security key?
• Is there an overall communication plan?
• What number can users call when something goes wrong?
• Etc.

User experience – Passwordless Windows enrollment

Let’s assume I’m Jessy Wonka and my brand new Windows 11 laptop was just delivered at my doorstep. When I open the package, I also see there’s a security key delivered with it. The day before I received an e-mail informing me about my users name and the onboarding process. My firm requires me to Identify myself, before I’m allowed to receive a TAP. After Identification, I receive my TAP. I now have to complete the device enrollment within 8 hours. Otherwise, I’ll have to get myself a new TAP.

So let’s boot up a Windows 11 and see what happens…

The device enrollment process is running smoothly and before I know, the process completes.

Upon completing the device enrollment, I’m able to configure Windows Hello for Business. Depending on what kind of device you have, the options might vary. For example, you might have biometrics and face recognition. If not, then you complete the Windows Hello for Business by configuring a PIN.

Note: if you are not able to configure Windows Hello for Business during autopilot, you will not be able to sign-in to the device without a password. So make sure the autopilot process is working flawlessly.

Then, like magic, you end up at your desktop. The device is now ready for use. Wait what? This was a full passwordless experience.

The next time I sign-in to my device, I can do so with my Windows Hello for Business PIN.

Looking at my sign-in options, I see that there are three options:

• Password
• FIDO security key
• PIN

Note: The password credential provider has not been removed here. That is why I still have the option to sign-in with a password. However, I don’t know what the password is. So this leaves me with one option for now. Windows Hello for Business PIN.

User Authentication methods

If we look at the authentication methods for Jessy, we can see that Jessy only has two options to authenticate; TAP and Windows Hello for Business PIN.

This means, Jessy can only sign-in on this particular desktop, and nowhere else at this stage! So the next thing to do, is to add a security key, or another authentication method like the authenticator app for phone sign-in. Otherwise, we cannot sign-in from a browser on another PC. Remember that Windows Hello for Business is configured per device!

Azure Multi Factor Authentication

In my test tenant, I’ve also configured a conditional access policy requiring users to setup MFA. So before I can sign-in to any of the Microsoft 365 apps like SharePoint Online or Exchange Online, I’m gonna have to configure MFA first.

Note: It’s important to understand that in this passwordless demo, I’ve configured TAP for one-time-use. When I logged on to my device using Windows Hello for Business, I have SSO to Azure so I can sign-in to https://portal.office.com, and when confronted with MFA, I’m able to configure MFA without any issues. If I do not configure MFA on this device, and try to do that on another device, I’m going to have to sign-in with a password (or security key) before I’m able to configure MFA. And since I don’t know what the password is I can’t complete the request, unless I receive another TAP to configure MFA.

Setting up a FIDO2 Security key

Jessy Wonka goes to https://aka.ms/mysecurityinfo to configure other passwordless authentication methods. So on the brand new device Jessy received, she’s gonna configure the security key she received. One less excuse for passwords.

Note: Just like before while configuring MFA, it’s best to do this first, on the device she enrolled. If the TAP can be used multiple times during the activation hours, there’s no need to be on the same device (with SSO to Azure) to configure a security key or MFA.

• browse to https://aka.ms/mysecurityinfo
• Click Add sign-in method
• Select Security key
• Follow the steps to configure the security key

When all goes well, you’ll see the FIDO2 security key as an authentication method. The screenshot below shows that Jessy has also enrolled two Windows devices.

From this point on, Jessy is able to sign-in to any Azure AD joined device in her tenant using the security key, as well as sign-in using a browser on any (managed/unmanaged) device. Let me ask again; What is your excuse for passwords?

The pros and cons of passwordless

When thinking of it, here are some pros and cons of passwordless I can think of. One of the things to consider is a fallback scenario or an alternative authentication method in case someone loses a security key and needs to sign-in from an unmanaged device. Therefore, consider passwordless sign-in with Microsoft Authenticator (phone sign-in), a spare security key, both or some another form of authentication. You might also want to think of when you would need to create another TAP for a user, if they cannot perform MFA. For example, when a phone is lost or stolen. What is your excuse for passwords? Let me know below in the comments section.

Pros

• Duh…No password!
• Improves user experience
• With 15+ random passwords a brute-force attack is less likely to be successful
• Bye Bye Password Spraying. Not one password is the same!
• Windows Hello to sign-in on Windows device
• Stronger Cyber Security Posture
• Security key with biometrics for better experience
• Reduced Long-Term Costs
• I ask again… What is your excuse for passwords?

Cons

• Loss or theft of security keys (then again, people forget their passwords too)
• SIM swapping if you’re using phone sign-in
• Biometrics are not bulletproof
• Doesn’t protect against some malware
• Man-in-the-browser attacks are still possible
• End-User skepticism
• Deployment Cost and Effort?
• Think about fallback scenario

Other things to consider

In this example everything works out great! And that’s true for most cases but sometimes things do not work out that good. For example; Imagine that the Autopilot enrollment does not go as expected. What could go wrong right? 😊 Well, if you deployed endpoint security policies or security baselines to device groups, chances are, that the enrollment process is disrupted because the device unexpectedly reboots. Therefore, the Enrollment status page will continue when the user signs in with a password! Since you did not complete Windows Hello for Business, the only option you have at this point is to use a password. And that is just the thing we want to avoid and have no excuse for passwords.

In short: With a normal autopilot enrollment the user signs in once with a password or TAP, to enroll the device. The enrollment is successful if the user ends up at the desktop after configuring Windows Hello for Business without any reboots in between. So if you do run into these situations, make sure the Autopilot enrollment works without any issues.

Instruction video: What is your excuse for passwords?

I hope you’ve enjoyed this post. To better understand how things work, I’ve also created a instruction video showing you the configured back-end, and more importantly, what the enrollment process looks like from an end-user perspective. Let me know what you think.