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:
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.
Recommended and also not?
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
Targeted use via Privileged Identity Management with Conditional Access seems to be the optimal use case at the minute. A policy requiring FIDO2 authentication to elevate to directory roles such as Global Admin brings the security benefits to bear on sensitive activities without disrupting mobile access since it’s only applied to the act of elevating and not on an ongoing basis thereafter:
Question: What's better than peanut butter and jelly for an Azure AD admin?
— Merill (@merill) February 24, 2023
Answer: Our newly launched feature that adds conditional access policy support to Azure AD PIM.
Folks, this is a marriage made in heaven. Read on for a quick walkthrough. 🧵👇🏾 pic.twitter.com/wKqdZ8NUu7
This remains an edge use case though; as an industry we’re not going to progress to widespread use of phishing-resistant credentials without mobile support for WebAuthN and Passkeys.
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:
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; continued attempts to create a passkey using an Azure AD identity fail with an error despite provisioning correctly on the device:
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.