In my last post I looked at the state of authentication for non-technical folk, pointing out that there are too many barriers and an insufficient amount of scaffolding to lift them off the ground floor. The answer that’s come back from Microsoft and others is ‘just use FIDO2’ – but this apex method isn’t without its own issues.

No phone, no problem!

If you’re not familiar with what FIDO2 involves, have a look at this session from last year’s Microsoft Ignite; it’s one of the clearest explanations I have seen.

Sound good? Let’s look at the kind of people who are likely to need this most-secure-possible means of authentication. IT admins, finance folk, business leaders, board members, C-suite executives, department heads, legal and compliance and so on. High levels of access, high public exposure, high risk – and for the most part, highly mobile.

It’s just as well then that CTAP (the device-to-token component) and WebAuthN (the device-to-server component) are supported on iOS and Android – I recently added a FIDO2 key to my Bitwarden vault and have used that across mobile, desktop and laptop. Unfortunately for everyone in the Microsoft world, WebAuthN isn’t supported for Azure AD identities on mobile devices.

I tested this by associating a FIDO2 credential with my account and creating a Conditional Access policy requiring it for access, then logging in from my iPhone:

iPhone Screenshot

You can see the logon prompt hanging at the point where WebAuthN would step in to negotiate credentials with the device. This is where the wheels come off – both practically and conceptually.

Sometimes secure?

The MS Docs article listing supported platforms reveals limited support for desktop operating systems other than Windows and none at all for iOS or Android.

So to the CEO relying on an iPhone to take a Teams call in the car, the Finance Manager using an iPad on the sofa to balance budgets ahead of year end, the Facilities Head needing to attach a video of a break-in from CCTV to email on an Android phone, there’s only one answer at present: turn it off entirely or fall back to a less secure method.

I would argue the former is preferable, since when we train users to click on ‘use another method’ and fall back to the app or a TOTP, we are training them to fall for the first phishing attack that exploits that weakness. Simply having a phishing-resistant authentication method isn’t enough if it isn’t used everywhere.

It’s hard to imagine that this long-standing lack of mobile support for FIDO2 has not to some degree hampered its adoption across the many industries reliant on Microsoft technology, holding them back from achieving a greater degree of safety for their users.

I’ve heard it suggested that this delay is due to investment in Passkeys, the newer standard for multi-device FIDO credentials. It’s almost a year since this was showcased on the Azure AD blog as coming “in the near future”, with not a peep since. Given the scale of recent redundancies in Microsoft’s Identity team I’m not holding my breath for progress either.

With the recent release of the system-preferred MFA policy this situation is addressed, if rather obliquely. The documentation states “we highly recommend enabling system-preferred MFA in the near term for improved sign-in security” but includes this humdinger of a known issue:

FIDO2 security keys on mobile devices… aren’t supported due to an issue that might surface when system-preferred MFA is enabled. Until a fix is available, we recommend not using FIDO2 security keys on mobile devices… To disable system-preferred MFA for these users, you can either add them to an excluded group or remove them from an included group.

This statement seems to imply that FIDO2 keys are not supported on mobiles because of a bug with this policy when in reality they have been unsupported for some time. Further, it is not transparent about the fact that FIDO2 clearly doesn’t work on mobile and that the only way to avoid the issue is to disable it entirely or remove it as default so it would seldom be used.

Excels at edge cases

There are two current use cases for FIDO2 that can still make a good security impact in organisations of all sizes, provided AADP2 licenses are in place.

PIM

Privileged Identity Management can now include an authentication context for an elevation action:

This is a clever use case because it brings the security benefits to bear on sensitive activities without disrupting routine access since it’s only applied to the act of elevating and not on an ongoing basis thereafter.

Admin Portals

Targeting a CA policy requiring FIDO2 auth at the Microsoft Admin Portals will result in another limited application of its heightened security to the Exchange, Entra, Intune, Azure and M365 portals. This will not disrupt access outside of these portals and if a device that isn’t FIDO2-capable needs access, it can be given a deviceID exception.

Update 10/5/23

Last week Google launched passkeys across their personal and business accounts. Dan Goodin wrote a great piece at Ars covering the change. It’s really fantastic; in just a couple of minutes I was able to get Windows and iOS set up for Passkeys and log in on my phone:

Google account Passkeys

Intriguingly Google lumps FIDO2 hardware security keys in with device-based Passkeys and calls them all ‘passkeys’. I wonder if this will become a convenient catch-all term for any form of certificate-based authentication at some point?

Anyway, back in the Microsoft world we’re no further on for corporate accounts; continued attempts to create a Passkey using an Azure AD identity fail with an error despite provisioning correctly on the device:

Microsoft

Given the continued radio silence I hoped to prod out some details with a support ticket but that’s been a dead end. At least with recent developments in the space it seems likely that there’ll be some forward progress soon.

Update 8/6/23

There was a recent unannounced change to support for Safari on iOS as discovered by Nathan McNulty:

Sadly this only applies to hardware security keys (not Passkeys) and doesn’t include the integrated browser, so they still can’t be used in apps such as Teams and Outlook or in Microsoft’s Authenticator app. In the same thread, Nathan suggests that the delay in adoption of Passkeys may be due to the difficulty of restricting them to corporate managed devices. If true, this would certainly be making the perfect the enemy of the good since even on a personal device, Passkeys would be a good deal more secure than the majority of our current means.

Update 23/7/23

Within the last few days, there has been an update on the Windows Insider Blog revealing native support for Passkeys in Windows and Alex Weinert published an article on the Microsoft Security Blog announcing the inclusion of FIDO2 auth on iOS in Safari (as discovered by Nathan last month). There’s still no news on native app support for mobile devices or passkeys in Azure AD.

Alex linked to a recent academic paper his team published regarding the effectiveness of MFA. Sadly their research wasn’t specific to enterprise contexts or modern methods, discovering mainly that MFA of any kind is 98.6% effective in actual cases of known password compromise and that SMS is 40% less effective than Microsoft Authenticator. These findings are not at all surprising (though I’d have predicted worse odds for SMS). I’d be much more interested in the view of known compromised organisations and how their various forms of MFA fared against more sophisticated and targeted attack and a comparison between older / weaker methods and newer / stronger ones.

Update 9/11/23

There is a session at the upcoming Microsoft Ignite conference called ‘bringing Passkey into your passwordless journey’. Perhaps there will be an announcement made regarding plans for future support.

Update 2/1/24

As reported by Fabian Bader, at long last native app support has arrived in public preview for iOS with Android coming later in the year. Support for device-bound passkeys is also imminent. It seems the gap is finally closing!


Comments