The Current State of ‘Password-less’ in the Microsoft Cloud

‘Password-less’ is the new buzzword in ‘Microsoft Cloud Security’ land.
Basically it ushers in ‘The Future of Authentication’, promising easy, but very secure, access to your Cloud resources by eliminating the need to think up, remember (and periodically change!) the traditional password that goes with a user name.
This is a great idea because easy to remember passwords are still one of the major attack vectors any hardcore hacker or ‘script kiddie’ will employ to hack all y’all.

Go Password-less!

Most organizations, especially the ones using Big Tech’s ecosystems, have already added MFA to the mix, making pwning¹ the password of some unsuspecting user less relevant. However, while it is well known that a second authentication factor consisting of a only ‘SMS’ or ‘alternate email’ can be hijacked quite easily (Channel-jackable), the latest hacking technique employs a MitM to spoof the Big Tech logon page and redirect the acquired tokens to the attacker, who will now have access to the users data (if no other measure have been put into place). This can happen even when the user is using the Microsoft Authenticator App push or notification features as their second authentication factor (Channel-jackable).

Ouch!

The technique is generally used in Real-Time ‘spear phishing’ campaigns (ie. very targeted!) and may happen because the Microsoft authentication servers are not verifying the requestor URL as part of the authentication sequence.

Another method that is quite popular relies on the set-up that the Microsoft Authenticator App is the only element in the authentication process (satisfying both first and second factors). In this scenario the attacker only has to know the target’s sign-in name (UPN) to start ‘annoying’ the target with random push notifications on their App which can lead to MFA fatigue.

So, in my search for alternate options which are more secure in the ‘wild wild web’ authentication conundrums I came to a sad conclusion.
There are no ‘Open’, ‘Cross-platform’, ‘Phishing resistant’ Password-less sign-in methods for the Microsoft Cloud, even after the concept had been introduced in 2018 already.

What are the options available?

• Windows Hello for Business -> Windows only. Period! But that’s fine, works nicely for the most part (excluding the issues with the latest Windows 11 22H2 update) and remains ‘phishing proof’.
  Great option if you want and can have all your users firmly in the Microsoft ecosystem.
• Microsoft Authenticator App -> WARNING: These Apps (available on iOS and Android) are like I previously explained: vulnerable to phishing AND MFA Fatigue. Otherwise this option is great for universal access anywhere and from every device.
• FIDO2 security keys -> WARNING: Vendor lock-in detected. These ‘hardware tokens’ are only ‘universally usable’ in Windows context with ‘specific’ Chromium browsers. I won’t consider FIDO2 a viable option to access the Microsoft Cloud until full Linux+Firefox and Mobile support is available.
  Here follows an opinion: The dependence of this ‘FIDO2 Standard’ on implementers who, of course, favor their own clients and software (in this case Microsoft favoring Windows and Edge), effectively (almost) forgetting about alternate ecosystems, together with the ‘closed nature’ of the hardware development might cause this Standard to self-destruct at some point.
  This state of affairs should be considered a serious risk for any (aspiring) CISO to invest in this method.

Finally, although not truly Password-less, because the ‘password method’ needs to remain enabled for this Authentication Method to work (at least in the Preview), I would like to mention the following method anyway because it might just emerge as the über-Password-less option in the future (I have high hopes in any case):

• Certificate Based Authentication (in Preview) -> WARNING: Certificates have to be linked to User Sign-in name (UPN) instead of requiring only certificate Thumbprint matching on any Azure AD account property AND Mobile support is tricky AND managing the CRL location is a burden AND managing the PKI infrastructure (Especially lack of OCSP and LDAP revocation checking) is not on par in this Preview. Read some more about CBA.
  Earlier this year Microsoft updated this offering in such a way that an on premises ADFS set-up is no longer required to enable CBA. All the authentication assets are now configured by Azure AD (and Intune). Most of the hurdles mentioned above can be made ‘manageable’ by using Intune and its Simple Certificate Enrollment Protocol (SCEP) profiles. I found a great blog about just this subject
  Here follows an opinion: But there are some things I dislike about this approach.
  • I would like to add CBA to un-managed devices (No Intune!) as well and still have great manageability.
  • Furthermore needing an on-premises Windows Server machine joined to a local AD that is running the Intune connector to serve certificates seems both archaic and like yet another vendor lock-in / up-selling strategy.
  • I would like to see an option to have the end user upload their own certificate (the public part) as a sign-in method to the Security info section of their Account Portal. I would imagine that Microsoft can make it so that, on upload, the Subject Key Identifier (SKI) hash of the Public Key is automatically added to the Azure AD profile after the certificate is checked to be generated by the correct Root CA certificate and that the hash is configured to serve as ‘binding’ during authentication. The private key being on the Users machine/browser, of course.

So even though enrolling and managing these User certificates is a hassle, together with a lesser user experience compared to FIDO2, it still might become the only phishing resistant, cross-platform and cross-browser authentication method because the techniques involved are very well established on all platforms.

Will we see this method leaving behind the proprietary FIDO2 hardware solutions, while it becomes more mature? We will see.

As a parting note: I would really like to be able to use CBA (as a first factor, effectively replacing a password) in combination with the Authenticator App as a second factor at some point in the future. This would prevent both phishing and MFA fatigue in all likely business scenario’s. Sadly this configuration is not (yet?) possible, so join the discussion.

1. What does it all mean -> https://haveibeenpwned.com/About ↩