Coming soon to an Azure AD/Microsoft 365 subscription near you: Life without passwords?!Alex Fields
- Require passwords have at least 8 characters. Longer isn’t necessarily better, as they cause users to choose predictable passwords, save passwords in files, or write them down.
- Disable character-composition requirements, as they cause users to choose predictable character substitutions in passwords.
- Disable expiration rules, which drive users to easily guessed passwords such as Winter2018!
- Prevent users from choosing commonly attacked passwords
- Educate users not to re-use their work password elsewhere
- Enforce registration for multi-factor authentication
- Enforce risk-based MFA challenges
Pretty interesting advice all around, since it flies in the face of what we’ve been preaching and doing for years. As a supplemental note here, Microsoft has also published an article on how you can take specific steps to better secure your identity infrastructure, which follows the advice above as well as the Identity Secure Score assessment card. The Secure Score system, for those who don’t know, is an automated assessment that encourages you to enable better security controls within your Microsoft 365 / Azure AD tenant (and of course, to purchase more security add-on subscriptions).
But much of this advice could be flipped upside down with the ability to implement a password-less sign-in to Azure AD.
Microsoft also recently announced that for Microsoft accounts (not Work or School accounts in Azure AD, but “consumer” Microsoft accounts), we now have the ability to replace our passwords with Windows Hello, or with a FIDO2-compatible security key. In either case, the password prompt is never really required, and you get two-factor authentication in one single step.
With Hello, for instance, you can unlock a device using a local PIN or biometric, or some other local gesture. That secret never leaves the device, but passing that step verifies that the person in possession of the device is legit. The authentication to Microsoft’s servers in the cloud is then handled by the device itself using a public/private key pair–so when you unlock a device with your local gesture, the device signs on your behalf using the private key (which is stored on the hardware-based TPM, or in a software-based TPM).
Technically speaking Microsoft has been marketing this technology as “two-in-one-factor” (local gesture or biometric + private key stored on the hardware). But yubico, who partnered with giants Google and Microsoft in the development of FIDO2 standards, still calls this implementation–password-less–a single-factor. The debate here starts to get into some strange philosophical distinctions, but either way this form of authentication is considered much stronger than traditional passwords.
Password-less sign-in For Azure AD
We don’t have this same FIDO2-based capability yet with Azure AD accounts, but we are promised it is coming soon. However, you can already enable a “no passwords” experience for your users, and it all happens via the Microsoft Authenticator app. It works like this:
- Enable your tenant for the feature using PowerShell;
- Enable MFA for your users;
- Make them register for MFA using the Microsoft Authenticator app (pairing the mobile phone app with their account);
- When they sign-in to an Azure AD, instead of a password prompt, they are prompted to open the Authenticator app, and match the number that is displayed.
This mechanism is only in preview, and again, it does require using the Microsoft Authenticator app (latest version on iOS 8+ or Android 6+); but it is nevertheless another possible avenue for eliminating passwords. The FIDO2 thing is a pretty big deal, too, since it embraces a standards-based set of devices and protocols, in addition to what has been offered in the past. I get a surprising number of requests, especially from financial services companies, for hardware-based* MFA (rather than using the app or an SMS text). So I look forward to seeing that implemented also for Azure AD (sometime in Spring 2019, they say in their announcement).
To be clear, I have not implemented this yet. I am curious to see how it plays with various apps. I gather from reading that it may not work everywhere yet, and that there are other caveats to it. I notice also in the screenshot above that the password is still a fall-back option, meaning that you may still need to rely on it under certain circumstances (unless there is a way to enforce the no-password experience only?).
From where we stand today and looking forward, it would seem that this no-password thing sort of removes the need for “password guidance.” For instance, if you were to enforce a FIDO2-type of experience (remove the option to use a password in general), what good is a risk-based MFA challenge now? If a rogue actor tries to sign-in from China or some other foreign place, they are already going to be presented with this password-less experience–the “weak” or compromised password does not matter in this case. And why would a user ever need to self-service reset their own password at this point?
I have had this debate with others in the past, especially in regards to Conditional access and MFA–why wouldn’t you just require MFA in all cases, versus so-called “high risk” cases only? The answer usually comes down to user experience–avoiding that second step in situations that are deemed “less risky” just makes life easier–plus, you will notice, it helps to sell Azure AD Premium subscriptions! But a “no-password” setup like this one, using Hello or some FIDO2 device, might settle this argument once and for all–go password-less, and collapse two authentication mechanisms into one End of debate. Thoughts?
*Note: I have noticed that some of these hardware devices simply require you to tap a button on a USB stick inserted in the computer–I cannot imagine this is as safe as Windows Hello, where the private key is protected by a gesture that you either know (PIN) or are (biometric). After all, if anyone can pick up your USB key and then use it to login as you just by tapping a button–no bueno. I would personally go with Hello, or another hardware key that has some biometric such as a fingerprint scanner or facial recognition built-in.