Windows Hello and Compliance

kloset · ‎11-14-2019

Hi,

As companies are adopting "Windows Hello", I would like some feedback on how its viewed for compliance

As many of you know, for PCI and NIST, it is required to have a complex password and/or multi-factor authentication in use at the users endpoint.

With "Windows Hello" the end user has the option to use a 4 digit pin to logon to the workstation, facial recognition, or a password. The end user can choose which one to use.

Now, the Pin is only associated to that workstation, but I would expect the 4 digit pin to be less secure than a complex password. Any walk by user with knowledge of a 4 digit pin would be an easy logon.

Does the 4 digit pin 'Windows Hello' method meet the password complexity requirement for these and other compliance requirements?

denbesten · ‎11-14-2019

@kloset wrote:
Hi,
As companies are adopting "Windows Hello", I would like some feedback on how its viewed for compliance

Can't comment directly on PI-DSS, but rather than equating Hello to password practices, equate it to a phone unlock. Like a phone, Hello is device local (as @kloset notes), disables PIN/biometric authentication after a few failures and requires alternate credentials (i.e. an AD password) to restore normality. Microsoft has a pretty good Q&A explaining how they believe PINs and passwords differ.

One really cool thing is that Hello bifurcates your attack surface. If somebody shoulder-surfs a PIN, the bad actor has not gained the ability to login to your network accounts or RDP into your workstation. Plus, since users are entering their AD password less often, there are less opportunities for its compromise.

It is possible to set Hello complexity requirements, just as one does for a password. That said, there is a balance between data protection and user satisfaction. By reducing drag low on common activities such as unlocking workstations, one can more easily sell other improvements such shorter screen-lock timers, longer AD passwords and use of MFA when remote. In my organization, we did up the requirement to 6 digits to prevent years ("2019") and simple keyboard patterns ("0258", "74123").

kloset · ‎03-01-2021

Has anyone confirmed that Windows Hello PIN's, lets say 8 digits, meet PCI/NIST requirements.
Here is my understanding:

MFA requires 2 methods or more using these 3 aspects

Something you know (password, pin, secret questions/answers)
Something you are biometric method (finger print, retna scan, facial recognition)
Something you have ( authenticator app code, RSA phob, smart card)

Windows Hello ties/binds pin to the single device, prevents using the PIN on other devices.

A Pin is something you know not different than a password. To meet compliance something you have (device with TPM chip) or something you are is still needed to meet MFA req's,

This PIN would apply to the single user device with a TPM chip, but it does not meet the req in VDI environments, where passwords and MFA are still needed.

Windows Pin is something you know, which is not different than a password.

When coupled with Something you are and/or Something you have, the pin would meet the PCI/NIST requirements.

However PIN Complexity is subject to the same requirements: Complexity, Length, Expiration, History

This prevents shoulder surfing/walk by password compromise.. A 4 or 8 digit pin does not meet this requirement

You can require special characters, uppercase, lowercase, and digits in the Windows Hello configuration.

Howardmp1

Hello,

Not sure if this thread is still alive but I do have concerns about WHfB being considered MFA when PIN is used.

In my scenario 1) the user deliberately switches off laptop camera, and is guilty of having post-it-pad with 6 digit PIN (I'm sure this still happens!), 2) WHfB authentication also flows through to VPN and Office 365, with no external challenge (i.e. mobile or token based such as MS Authenticator or RSA). 3) Device is then either deliberately shared for convenience, or lost stolen.

In this scenario, there is only strong device based authentication, but this is irrelevant because it is the device you are connecting from, and no strong user based authentication because it has been switched off. So the unauthorized user has all the access that the authorized user would have. to me this feels like MS claim that WHfB prevents lateral movement is only true if the authentication is not chained to VPN pr or Office 365

From a pure compliance perspective, it looks like it would fail against NIST IA-02(07)?

Grateful for any thoughts or discussion,

Many thanks

Howard

denbesten

Let me first start with some background:

Windows Hello is inherently multifactor authentication because it is only usable when one is in front of the device itself ("something you have"), with MS always requiring it be accompanied with face/fingerprint ("something you are") or a pin ("something you know"), adding that second factor.

Windows Hello for Business is a different product. It is fundamentally certificate-based authentication with the added twist that the private key must protected by Windows Hello. It is this twist that ensures WHfB is multifactor.

Certificate-Based Authentication (CBA) has a "public key" stored on the server and a "private key" stored on the client ("laptop"). These work together to allow the client to authenticate the user on behalf of the server. The authentication ceremony is the user "smiling for the camera" on the client to retrieve the private key. Use of the keypair is reporting the ceremony's success; it is not a separate authentication ceremony in and of itself. It was configuring CBA that authorized this "outsourcing" of the ceremony to the client.

CBA itself does not inherently have a particular number of factors. Instead, the factor-level depends upon how the private key is protected. If stored publicly, CBA would be zero-factor authentication. If the private key is stored on a password-protected laptop (e.g. in a file or the windows certificate store), the CBA is considered single-factor. And if the private key is stored in a TPM accessible only via Windows Hello, CBA becomes multi-factor.

Incidentally, "A memorized secret [i.e. a PIN] is something you know" by definition. Writing it down does not change the definition. Nor does storing a password in a vault. Regardless of how it is stored, it is considered "something you know" for purposes of determining 1FA vs MFA.

Now, onto your question, "From a pure compliance perspective, it looks like it would fail against NIST IA-02(07)?". Presumably you are referring to NIST SP 800-53, version 4, which states:

The information system implements multifactor authentication for network access to nonprivileged accounts such that one of the factors is provided by a device separate from the system
gaining access and the device meets....

Since both Windows Hello and by extension WHfB require MFA, the first half of the sentence is satisfied and since the face, finger, and PIN are not inherently part of the phone itself, the second part is satisfied.

Regarding lateral movement, check out this article.

Finally, two small requests. When referring to standards (especially in an abbreviated fashion like "NIST IA-02(07)"), please include a hyperlink so that we know for sure what you are referencing. And secondly, version 4 was withdrawn in 2021 (see page 1), in favor of version 5. It is best that one uses current references.

Howardmp1

Hello Denbesten,

Thank you for your detailed analysis.

Based on this, I must agree that the fallback to PIN with TPN does still meet MFA definition.

I would however, contend that whilst it is strong authentication for the device, PIN or password is weak authentication for the user identity as it can be circumvented by simple things such as post-it-pad and shoulder surfing.

What's really concerning me at my organisation, is the architects in their PoC have somehow chained WHfB authentication to full VPN and Office.com, without the MS Authenticator challenge that is normally in place. When the user authentication element is strong with biometrics, this is great but if biometrics is unavailable or deliberately switched off by the user, we fallback to PIN which could be compromised as above and the unauthorised person has all the access rights of the authorised user across the estate - in your opinion, would PIN still be acceptable in this set-up?

thanks again

denbesten

You might read Microsoft's FAQ regarding PINs.

I think your bigger observation is that if you do not trust the device, you ought not trust any single-sign-on mechanism that trusts the device. Or put more positively, if one wants to use SSO (which both reduces authentication friction and enables us to add more checks), the device needs to include the standard corporate security precautions, such as remaining current on patches, use of bitlocker, automatic screen-lock etc.