With the availability of passkeys the FIDO2 standards become more accessible in the form of password managers, web-browsers and (mobile) operating systems — without the need for dedicated hardware such as FIDO2 keys.
Microsoft is currently in the process of developing support for passkeys and shipping the public preview in Q1 2024:
While this is a very welcome addition to make passwordless authentication easily accessible without dedicated hardware such as FIDO2 security keys this also introduces new risks, especially for high value accounts — But why’s that?
Let’s imagine a fictive scenario (that might become reality in the future) of a user registering a passkey with his password manager app for a Microsoft Entra account. The security of this passkey is now determined by the security measures on the password manager app.
For the Microsoft roadmap this scenario is not (yet) applicable as Entra will only support device-bound passkeys. At the end of the day it is a similar situation as the security of the passkey depends on the device with the authenticator (passkey) on it and that’s not necessarily under the umbrella of IT security measures.
Fortunately there is hope and the FIDO alliance included that critical aspect of distinguishing authenticators in their standards as we’ll find out below.
Attestation and AAGuids
Each authenticator that complies to the FIDO2 specification needs to support a thing called attestation. This is basically a proof about the authenticator that is backed by a certificate to indicate information about an authenticator such as the vendor, model and compliance with standards such as FIPS.
This attestation proof contains an unique identifier for the respective authenticator type, also called Authenticator Attestation Globally Unique ID (AAGuid). IdPs such as Entra ID can and should enforce attestation and can optionally enforce key restrictions. Key restrictions take effect for the registration and usage of FIDO2 security keys and passkeys as attestation info is sent during the registration and also the authentication.
During the registration and authentication process, a FIDO2 security keys and passkeys will send attestation info within the request information. The AAGuid info during the registration can also be extracted via KQL from the Entra ID audit logs:
Lookup of AAGuids via FIDO2 MDS Blob
The AAGuids itself don’t come in a human readable format. The FIDO alliance publishes a Metadata Service (MDS) blob in the format of a signed JSON Web Token (JWT) that contains a list of all certified authenticators, including additional metadata and the corresponding AAGuids.
Unfortunately this information is not exposed by the FIDO alliance in an accessible way and parsing the MDS blob manually is also poor from an admin perspective. Therefore I built a little web app called AAGUIDs, that pulls and parses the latest MDS blob on a daily basis and allows for easy AAGuid lookups.
Additionally, the passkey developers maintain a semi-official-ish repository (passkeydeveloper/passkey-authenticator-aaguids)of vendor-sourced AAGuids for passkeys that is combined with the FIDO MDS blob. I also daily pull and update a copy of that file, this can also be displayed within my web app by enabling the respective toggle:
One thing I am actually curious about is whether the passkeys will be added to the FIDO MDS blob, at least with the scheduled update for the 01.12.2023 they did not appear.
Detecting registered FIDO2 security keys with KQL
With the gained knowledge about the FIDO MDS blob we can combine this information with the previous query about registered FIDO2 keys and their AAGuids. We can simply lookup the FIDO2 or Pass-Key based on the AAGuid.
You can use the following JSON for an externaldata lookup: ITDR/Watchlists/aaguids.json at main · nicolonsky/ITDR (github.com).
Authentication method enforcement and downgrade (attacks)
To enforce passkeys and FIDO2 security keys with Entra ID we have the following options available:
- System Preferred MFA: Entra ID will automatically suggest the most secure authentication method as default sign-in option. This is not really an enforcement but rather a nudge
- Authentication Methods: These control the available options, by disabling unwanted methods, you can allow only FIDO2 or Pass-Keys for specific personas
- Conditional Access: With the Authentication Strength Grant Control you can enforce a specific authentication method, either during sign-in or as part of an authentication context that can be used within Privileged Identity Management (PIM) or protected actions
Buuuuut what’s actually even cooler is the capability that hides within the authentication strength configuration! Here we can enforce a specific FIDO2 authenticator based on the AAGuid and embed this within our Conditional Access Policies.
With that approach we can once passkeys become available in Entra ID build more fine grained authentication requirements for sensitive personas and still enjoy the benefits of passkeys.
Hunting for Authentication Method downgrades
Without the enforcement of a specific authentication strength the weakest link will be the weakest MFA option registered on a specific account. Unfortunately the Entra Sign-In logs do not indicate when a user bypassed system preferred MFA (it would be cool to store this within an error code or dedicated system preferred MFA field in the logs).
Based on past sign-in logs and used authentication methods we can rank and compare the individual authentication methods and hunt for potential downgrade attacks or scenarios where a user leveraged a weaker authentication method.
Summary
FIDO2 and passkeys are the future when it comes to passwordless and phishing resistant authentication methods. While the security of the methods differ, FIDO2 security keys will still be the gold-standard for sensitive accounts such as admin and VIP accounts. It is therefore important to think about the allowed FIDO2 and passkey options for the respective personas and putting the necessary enforcements into place to make sure that these new and more secure authentication methods are also used and a downgrade to weaker authentication methods such as password and MFA is not performed.
