Passwordless with YubiKey

Passwordless Authentication is a topic I’ve been keen to write about for a while now. Last weekend I finally managed to grab some time to get to grips with one piece of the passwordless puzzle I hadn’t had a chance to play with: YubiKey.

The concept of “passwordless” doesn’t really need explaining… the clue is in the name 🙂 It is something that’s had a lot of press in recent months though as it’s matured to the point of being near GA for Azure AD. When exactly it will exit preview is anyone’s guess… but I’d speculate an upcoming industry event may yield some news! Irrespective, it’s highly relevant and exciting functionality that has the potential to siginificantly reduce the risk of data breach through poor password practice.

Before we get into some detail, why is passwordless such a big deal? I spent a bit of time covering the concept in a theatre session I ran this last week at Future Decoded. A “problem” I think we all accept relates to use of (specifically bad practice with) passwords. Regardless of how much education goes into encouraging good password practice, the reality is that:

• People will often re-use passwords between different services.
• Variants of the same password are frequently used to get around password age or complexity requirements.
• Weak or default passwords are regularly exploited by attackers.
• Passwords are frequently exposed through data breaches, stolen / leaked credentials, or phishing attacks.

In 2019, passwords simply aren’t enough. They need to be supplemented by solutions like multi-factor authentication, or biometric verification. Ideally access via password alone should be eradicated altogether. Here’s where passwordless authentication steps in, replacing traditional passwords with a modern alternative to verify identity.

What are the Options?

There are several routes to implementing passwordless sign-in available already:

Whilst these don’t (yet) lead to a state where users are truly passwordless, it does mean that use of the password can be minimised. This can, in turn, lead to a place where much more robust password policies can be implemented without upsetting end users.

Many of you will be familiar with Windows Hello which uses device hardware to identify and verify a user login attempt. The issue with Hello is the need for specific (and often expensive) hardware to ensure the appropriate level of security. Integrated cameras with near infrared (IR) imaging capability, or high-quality fingerprint readers aren’t always incorporated into company procurement strategies…

An alternative is Microsoft Authenticator based passwordless sign-in. This has been in public preview for some time now. When deployed via the authenticator app, a passwordless policy prompts users to verify one of three numbers in place of supplying a password during sign-in. Coupled with biometric authentication on the authenticator app itself (e.g. TouchID, or FaceID on access), this provides a trusted mechanism for verifying the user identity without the need for password entry. It also satisfies MFA is this forms part of your Conditional Access strategy. This is a simple, low-cost solution to passwordless, but has the potential to be resisted in some organisations by users who object to installing a work application on a personal phone. In organisations where company devices aren’t issued routinely, this can be a barrier to it’s use. It surprises me to this day that individuals take issue with this… but there you go…

This brings me on to YubiKey.

YubiKey Passwordless Authentication

YubiKey is built upon Azure AD’s support for FIDO2 security keys (also in Public Preview). These devices allow sign-in using a physical device assigned to a user profile in tandem with a PIN number. When configured, Azure AD users can sign-in to both devices, and web portals without needing to specify a username or a password. Crucially for businesses, this also provides a mechanism for passwordless without expensive hardware, or the imposing of a mandatory mobile app.

So how does it work in practice? Let’s take a look through a typical example using the Office 365 web portal. When accessing portal.office.com, you will notice a new “Sign-in options” link below the username prompt. Clicking this link will present the following screen:

Selecting the “Sign in with a security key” prompt will trigger a request for the user to insert their security key:

Once inserted, a PIN number known to the user (and configured during key registration) is also required to verify the user identity:

Finally, we are prompted to touch the key to continue. This completes the sign-in process and we’re in… no username, and no password. A joy!

Pre-requisites for FIDO2 Passwordless Authentication

So how do we achieve password-less sign-in with a YubiKey? Let’s start with the pre-requisites. You need to have a supported FIDO2 key. I’ve based this post on YubiKey (from Yubico) who are perhaps the most well known, but there are others. A list of supported vendors is available on the Microsoft Docs Passwordless authentication page. You also need to ensure:

• Users in-scope are registered for Azure MFA
• Users are assigned to the combined MFA / SSPR registration preview
• Windows 10 1809 or higher is installed (1903+ preferred)

The latter point is applicable to both Windows sign-in, and web sign-in where Microsoft Edge on Windows 10 1809 (or higher) is required. It’s worth noting that the new Chromium based Edge browser is also supported.

Your tenant will need to have the “Use security keys for sign-in” setting enabled within Microsoft Intune > Device enrollment > Windows enrollment > Windows Hello for Business > Properties (Windows Hello for Business is not a pre-requisite however).

The combined MFA / SSPR experience can be found under User Settings > User feature previews within the Azure AD portal. It can be enabled for all users, or a subset of test users within an Azure AD Security Group:

Configuring FIDO2 Security Key Sign-In

Once the pre-requisites are in place, you can enable your Windows devices for FIDO2 security key sign-in. Note, this step enables Windows sign-in, and is not required for web authentication via security key. The easiest way to configure this is via Intune:

1. Sign in to the Azure Portal
2. Browse to Microsoft Intune > Device configuration > Profiles > Create profile
3. Configure the new profile with the following settings
   1. Name: Security Keys for Windows Sign-In
   2. Description: Enables FIDO Security Keys to be used during Windows Sign In
   3. Platform: Windows 10 and later
   4. Profile type: Custom
   5. Custom OMA-URI Settings:
      1. Name: Turn on FIDO Security Keys for Windows Sign-In
      2. OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
      3. Data Type: Integer
      4. Value: 1
4. This policy can be assigned to specific users, devices, or groups

We then need to enable our test users for FIDO2 security key sign-in. Navigate to Azure Active Directory > Security > Authentication methods > Authentication method policy (Preview). In here, modify the properties of FIDO2 Security Key to target your test accounts:

The final step is to register a Security Key against the user. This is completed using the new “My Profile” administration portal under the context of the user. Click through to “Security Info” and select the option to add a method. In the resulting prompt, select “Security key” and follow the registration wizard through to enable the key against the account. This will include the creation of a security PIN for the device.

On completion, you’re done! You should be able to successfully authenticate using your security key via a browser. You will also be able to choose the “FIDO2 Security key” option at the Windows login screen once your Intune policy has applied.

Conclusion

Passwordless sign-in, irrespective of your chosen route is a huge step forward in securing authentication for your users and data. Whilst the underlying password is still present on the user object today, I foresee a time where its only purpose is to provide initial validation ahead of strong authentication setup. I’ve been using passwordless (in all three of its forms) for the last year or so now and I wouldn’t dream of going back… Do I know my password? I think so…(!) Do I want to have to enter it at every logon vs. pushing a button, or staring at a camera? Not a chance.

I suspect for most, Windows Hello or Microsoft Authenticator will be the preferred route for passwordless. The addition of FIDO2 to the stable is a nice touch for those organisations struggling to accomodate specialist hardware, or user on-boarding via BYOD MFA. Whatever your preference, I’d encourage you to take a look at passwordless. It’s a revelation for the end user… 🙂