Microsoft details how Windows Hello enhances Edge security

Microsoft announced at Build 2016 that Windows Hello support will be coming to the company’s Edge browser. Integrating Windows Hello into Edge will bring the convenience and enhanced security of Microsoft’s biometric solution to Web sites, which will make it easier–and thus more likely–to implement robust security. Today, the Microsoft Edge Dev blog provided some additional details on precisely how Windows Hello will be applied in Edge.

Here’s the impetus behind the integration:

Passwords can be a hassle. Most people don’t create strong passwords or make sure to maintain a different one for every site. People create easy-to-remember passwords and typically use the same passwords across all of their accounts. Surprisingly – and if it’s not surprising to you, you may want to change your password – passwords like “123456” and “password” are very common. Malicious actors can use social engineering, phishing, or key logging techniques to steal passwords from your machine, or they can compromise the server where the passwords are stored. When the same password is used across several sites, compromising one account can expose many others to abuse.

We look forward to a web where the user doesn’t need to remember a password, and the server doesn’t need to store a password in order to authenticate that user. Windows Hello, combined with Web Authentication, enables this vision with biometrics and asymmetric cryptography. In order to authenticate a user, the server sends down a plain text challenge to the browser. Once Microsoft Edge is able to verify the user through Windows Hello, the system will sign the challenge with a private key previously provisioned for this user and send the signature back to the server. If the server can validate the signature using the public key it has for that user and verify the challenge is correct, it can authenticate the user securely.

In other words, by making security more invisible and less intrusive to the user, Microsoft can increase the likelihood of users and Web sites implement robust security measures. No longer will users not to device and manage their own strong passwords–Windows 10, Windows Hello, and Edge will provide a platform to take away that burden entirely.

Some of the methods that will be utilized include the following. Much of this requires the cooperation of a number of organizations and Web developers in general, but it lays a strong foundation. Here’s a summary.

Web Authentication: Passwordless and Two Factor Authentication

We’ve been working at the FIDO Alliance with organizations from across the industry to enable strong credentials and help move the web off of passwords. The main goal of the FIDO Alliance is to standardize these interfaces, so websites can use Windows Hello and other biometric devices across browsers. The FIDO Alliance had recently submitted the FIDO 2.0 proposal to the W3C and the newly formed Web Authentication working group is standardizing these APIs in the W3C Web Authentication specification.

Registering the user

To use Web Auth, you, the identity provider, will first need to create a Web Auth credential for your user using the window.webauthn.makeCredential method.

When you use the makeCredential method, Microsoft Edge will first ask Windows Hello to use face or fingerprint identification to verify that the user is the same user as the one logged into the Windows account. Once this step is completed, Microsoft Passport will generate a public/private key pair and store the private key in the Trusted Platform Module (TPM), the dedicated crypto processor hardware used to store credentials. If the user doesn’t have a TPM enabled device, these keys will be stored in software. These credentials are created per origin, per Windows account, and will not be roamed because they are tied to the device. This means that you’ll need to make sure the user registers to use Windows Hello for every device they use. This makes the credentials even stronger – they can only be used by a particular user on a particular origin on a particular device.

Authenticating the user

Once the credential is created on the client, the next time the user attempts to log into the site, you can offer to sign them in using Windows Hello instead of a password. You will authenticate the user using the window.webauthn.getAssertion call.

The getAssertion call has a number of optional parameters, but the only required parameter is the challenge. This is the challenge that the server will send down to the client. This challenge is a random quantity generated by the server. Since the challenge is not predictable by an attacker, the server can be assured that any assertions it receives were freshly generated in response to this challenge and are not replays of earlier assertions. The allowList parameter also takes an optional list of credential ID information to locate the correct private key. This information is useful if you’re doing two factor auth and you can share the id from the server, where it is stored. In the passwordless case, you don’t want to share the id from the server because the user hasn’t yet authenticated.

Server side authentication

Once you receive the assertion on the server, you will need to validate the signature. The below Node.JS code shows how you would validate the signature to authenticate the user on the server. We also have the same code available in C# and PHP.

Evolving Web Authentication standard and Microsoft Edge implementation

As mentioned above, Microsoft Edge has an early implementation of Web Authentication and there are a number of differences between our implementation and the April 2016 spec.

• Microsoft Edge APIs are ms- prefixed
• Microsoft Edge does not yet support external credentials like USB keys or Bluetooth devices. The current
• API is limited to embedded credentials stored in the TPM.
• The currently logged in Windows user account must be configured to support at least a PIN, preferably face or fingerprint biometrics. This is to ensure that we can authenticate the access to the TPM.
• We do not support all of the options in the current Web Auth spec draft, like extensions or timeouts.
• As mentioned earlier, our implementation requires that the list of acceptable credential IDs be included in every getAssertion call.

If you’re a developer and need to get a head start, then Microsoft has a number of resources available to you:

• Webauthn.js polyfill. Using this polyfill, you can code to the standard instead of our early implementation. We’ll update this polyfill for every major published version of the specification.
• Windows Hello in Microsoft Edge test drive sample. This test drive sample shows you the typical client side registration and assertion flow.
• Server and client side WebAuth This sample code shows the end to end client and server side flow for registration and assertion.
• C#, PHP, and JS server side sample. These code samples show how could implement your server side logic in a number of language options.
• Web Authentication MSDN documentation and dev guide.

Windows 10 offers up a number of advancements over previous versions of Windows, and enhanced security is just one of them. We’re looking forward to the day when we can use Windows Hello to authenticate to Web sites and remove one more reason to remember those long and hard-to-recall passwords.