Getting Started with Microsoft Passport, Windows Hello and Office 365

In Windows 10, Microsoft introduced “Windows Hello” which – to keep things simple – offers the ability to use biometrics to unlock a computer instead of using a regular password.  But the fact that you can use biometrics for authentication purposes is not really new. Given this, you might wonder what is so special about Windows Hello. The answer lies in the combination of Hello with another feature.

Along with Hello, Microsoft introduced another new feature that didn’t get as much attention: Microsoft Passport. The simplest way to think of Passport is as a replacement for reusable passwords. While Hello can be used to unlock a credential, Passport lets you replace traditional passwords with much stronger cryptographic credentials.

Passwords are, because of the way people use them, inherently insecure. In recent years, researches have suggested that moving from regular passwords to passphrases could help solve the problem of short (even if complex) and insecure passwords. The following xkcd cartoon clearly illustrates that point:

However, recent studies such as this "Linguistic Properties of Multi-Word Passphrases" suggest that even passphrases can be easy to crack. Researchers Bonneau and Shutova concluded that people tend to revert to using words or word combinations that are commonly used in their natural language, making them easier to guess using a dictionary attack. As a result, a typical 4-word passphrase probably provides less than 30-bits of security:

This doesn’t mean that passphrases are insecure. To the contrary, as the cartoon illustrated, longer passwords, even if they are based on common word-combinations, take considerably longer to crack. As such, it’s quite surprising to learn that the maximum password length in Azure Active Directory is 16 characters. While 16 is probably more than most of the passwords, it does not even allow for a simple passphrase as the one used in the cartoon…!

In order to explain why Hello in combination with Microsoft Passport is different, let’s first take a somewhat simplistic look at how typical authentication (to e.g. Office 365) is done. The following image illustrates a user trying to access e.g. Outlook Web App. For sake of simplicity, I omitted the itty-nitty details, as I only want to illustrate the principles behind standard authentication.

• The user connects to the resource. Amongst many other things, this could for example be Outlook on the Web or SharePoint Online.
• Because the client is unauthenticated, the authentication service (in this case Azure Active Directory) will send the client a “challenge”. What it boils down to is that the user is asked to provide his credentials.
• The user (client) enters his credentials and sends them to the authentication service which, in turn, will verify the credentials. If the user is a federated user, the authentication service will either redirect the user to the AD FS endpoint or verify the credentials for the user with the AD FS infrastructure of the user’s organization.
• If the credentials have been verified correctly, the resource is “unlocked” and the user is granted access.

In theory, the last step is not entirely correct. Upon successful authentication, the user will get a logon token which it then can use to request access to a specific resource (e.g. Outlook on the Web). This is the difference between authentication and authorization. But for sake of brevity, let’s just assume the user is granted access to the resource after the authentication happened.

In this scenario, the password traveled ‘across the wire’ which means that it potentially can be intercepted. Although doable, it’s not as easy as it sounds. The password itself does not travel over the internet in plain text. The connection between the client and, in this case, Office 365 is secured using TLS. Often, the password itself is also hashed within the TLS-protected connection, adding another layer of security. This also isn’t the biggest risk.

So, why Windows Hello and Passport? The answer is, once again: because of passwords. Passwords are often too simple, too short and reused multiple times across multiple applications or websites. An attacker who can steal one password may be able to leverage it across multiple sites. Most of these issues can be attributed to user carelessness. On the other hand, can you really blame them? An average user has to keep track of multiple credentials and a human brain just isn’t made to remember long cryptic combinations of characters. Password management tools can help with remembering password. But then, those tools are often protected by a single password themselves…

For as long as I can remember, organizations and vendors have tried reverting to multi-factor authentication to tackle some of the problems associated with regular passwords. And, although partially successful, implementing multi-factor authentication is often complex and costly. On top of that, until recently, even Office did not properly support multi-factor authentication…!

The principle behind multi-factor authentication is that you authenticate using something you own and something you know. Typically, this is a combination of a password with a token like a smartcard or a one-time code which is generated every 30 seconds. In order to gain access to a system, an attacker would have to have access to both the token and the user’s password. Although it’s not as easy as just cracking a password, smart cards or code-generating tokens can be stolen. Nonetheless, adding an additional factor to the authentication is a huge leap forward in terms of authentication, but it does not take away all risks that entail the use of passwords.

The combination of Windows Hello and Microsoft Passport is also a form of multi-factor authentication with the exception that no actual password is used. Windows Hello in the current version of Windows 10 allows you to use the following gestures to unlock a device:

• Fingerprint
• Facial recognition using a specialized camera such as Intel’s RealSense camera.
• PIN code. You must set a PIN code before you can add/use any of the aforementioned biometrics. The PIN can always be used to unlock the device, for example in case biometrics cannot be verified.

All of these gestures are specific to one user on one device; that is, if you have 3 users sharing a PC, they each have their own separate PINs, fingerprints, or facial recognizers.

Note that biometric information is stored on the device itself. As such, there is no centralized infrastructure attackers could target in order to compromise a large set of biometric information at once. Even if someone would be able to get access to stolen biometric data, Windows Hello’s protocols are designed to prevent tampering with the data flow, greatly reducing the ability of an attacker to successfully use falsified or wrongfully obtained biometric data.

Microsoft Passport can be seen as a sort of credential vault; albeit that no real credentials (username/password combination) are stored. Instead, Passport uses cryptography which relies on the use of key pairs which are securely stored within hardware of the device itself (TPM). If no hardware is available, Passport can revert to software-based protection too. Unlike traditional smart card deployments and other multi-factor authentication systems which often also rely on cryptography, The simplest variant of Passport does not require any additional infrastructure to be deployed, making it a very easy-to-implement solution. Before an application can access specific keys inside the vault (known as container) the protector key which is used to secure the vault must be unlocked. The protector key is automatically generated by the TPM when the user registers a PIN or a (biometric) gesture. As such, the registered PIN or gestures can be used to unlock the protector key. Because each PIN and gesture are device-specific, the protector key cannot be unlocked by using a different device or by another user on the same device. Applications that are written to use the Passport API can request authentication from a web page or application, meaning that you get true single sign-on from within those applications.

Microsoft engineers sometimes use the analogy of a physical key in your pocket. When you take the key out of your pocket, it’s available but it isn’t being used for anything—that’s the equivalent of unlocking the vault. Using the key to open a lock is the equivalent of using Passport to authenticate access to a resource.
The following image depicts how Windows Hello and Microsoft Passport work together to authenticate a user to Office 365:

• The user attempts to login to (unlock) the local computer.
• Instead of entering a password, the computer asks for biometric input (facial recognition, fingerprint etc…). In case none of the biometrics are available, the user can revert to using the device-specific PIN code.
• In this scenario, the user’s face is captured by a specialized webcam (e.g. Intel RealSense or the camera built in to the Surface Pro 4 and Surface Book).
• Windows analyzes the biometric information from the capture and grants access to the local computer if it matches the information that was previously registered. The local Passport vault is also ‘unlocked’ allowing applications to request access to keys that are currently registered in the container.
• The user now tries to connect to Outlook on the Web using e.g. Microsoft Edge browser. In return to the client connection (and start of the handshake), Azure AD will send an authentication challenge to the client.
• The Edge browser uses the Passport API to request access to the identity provider (IDP) key for Azure AD, which resides inside the Passport container. That key is then used to sign the challenge and send it back along with the original (unsigned) challenge and the ID of the key that was used to sign the challenge. Azure AD then fetches the public key for the key ID which is specified in the response and uses it to verify that the signed challenge matches the original, unsigned, challenge. If the verification is successful, Azure AD returns a session key which is encrypted with the device’s public key and an authentication token which is signed using the session key. The device now uses its own private key to decrypt the session key and then uses that key to decrypt the authentication token. This authentication token is then used to gain access to e.g. Outlook on the Web or SharePoint Online.

Now that we have the theory behind us, how does this look like in real life? Because Windows Hello is part of Windows, there is nothing you have to deploy. Of course, you must ensure that you have the necessary hardware to support the various supported gestures. Most USB fingerprint readers will work, but the only supported camera for facial recognition is the Intel RealSense development kit camera, which I’m using in the steps below.  One word of warning: if you live in Europe, don’t forget that you’ll have to pay import rights on the device! (I learned the hard way…)

Until Windows Server 2016 comes around, you will not be able to deploy Passport authentication for resources that are part of an on-premises Active Directory. You can use Passport with Microsoft accounts right now; this means that you can enjoy the benefits with a regular Microsoft account or by joining your local computer to an Azure Active Directory instance. This would also be the first step. During the process of joining an Azure Active Directory domain, you will automatically be asked to setup a PIN. If needed be, you can configure policies which specify the PIN requirements such as the length of the PIN.
Once you have joined Azure Active Directory, and you have logged into the computer, open Settings and navigate to Accounts and then Sign-in options. On that page, locate the following section. Note that you will only see this section if you have compatible hardware (such as the RealSense camera). Click Set up.

Before you can register new biometrics, you are asked to enter your PIN. Once you have done that, you are taken to the Welcome to Windows Hello page. Click Get started which will automatically enable the camera and ask you to look at your screen while the camera registers your biometrics. This process merely takes a few seconds.

After the registration, you can click Improve recognition if you want to recalibrate the biometric data. This could e.g. help recognizing you in different lighting conditions. So far, I did not need to run through that process, although many users who wear glasses find that it’s required for accurate recognition.

That’s it. You are now ready to use Windows Hello (and Microsoft Passport). When you lock your device, you will notice that the Windows 10 Lock Screen now shows something similar to the image below. The camera is actively looking to recognize a face. During my testing, I found that unlocking the computer typically takes 1-2 seconds. By the time I properly sit down on my chair (in front of my computer), my computer is already unlocked.

Image: Windows Hello is waiting for you to appear in front of the camera

Image: Hello now verifies that your biometrics match. I tried using a picture of myself, but because of the infra-red camera, that (obviously) did not work.

Once you have unlocked your computer, there is almost no difference. However, during my testing I found that when you unlock a device with a PIN some network functionality might cause some troubles. For instance: I use a NAS (Synology) at home. When logging in with a regular password, I can access the shares on the NAS with no issues –provided that I authenticate with a username/password.
However, as soon as I unlock the computer with a PIN (or gesture), the NAS no longer recognizes the logged on user and I cannot access the shares. Part of this is because Windows 10, by default, disables the ability to insecurely access remote shares using guest access. The other part of the problem is that some servers (including my NAS) do not handle Azure AD accounts or pin-unlocked devices very well. This appears to be a known problem which, according to a conversation I had on Twitter, should have been solved in the latest 1511 build. Unfortunately for me, it still does not work. As a workaround, I re-enabled insecure guest access which work around the problem for now. As soon as I get more information from both Microsoft and Synology support, I’ll update the blog post here.

To finish up this article, let’s take a look at what the behavior is when using Office 365… As long as you use Passport-capable software such as Microsoft Edge, Internet Explorer or Office, you will no longer have to type your password to access Office 365 services using the account associated with Passport as you will automatically be authenticated and logged in. This means that if you open the Office 365 portal, you will not see the authentication screen by default!
However, you can log out from the portal, after which you will see the following on the authentication page:

Image: Office Portal account selection

The authentication platform knows that I am successfully authenticated to my local device; hence the mention of Connected to Windows. If I now click my username, I am automatically logged into the portal. Cool stuff, no?!