FIDO on MacOS: How it works, Attack Vectors and Other Learnings

Joel Rennich, who works on Mac authentication at Jamf, opens by framing FIDO and WebAuthn as a strong login option with rough edges worth understanding. He splits the model into three parts: the relying party, such as a website or identity provider, the platform, usually the browser, and the authenticator, which is either an external hardware key or Touch ID and Face ID on a Mac. He covers protocol details such as credential ID lengths and signature counters, and shows that Chrome and Safari behave differently, with Chrome producing 80-byte IDs and Safari returning zeroed counters.

The middle of the talk covers interfering with the flow. A browser extension can wrap the credential create and get functions, log the requests and responses, and modify them before the browser acts on them. Rennich demonstrates converting a platform authenticator request into a cross-platform one and inserting an attestation object. Using a software key he built, he gets past a Cloudflare challenge that expects attestation, and enrolls and signs in to an Okta test account without touching a hardware device. He also notes that Apple's synced platform keys in iCloud Keychain blur the platform and cross-platform categories that some services rely on.

For defenders, the takeaway is that user presence and key possession do not prove the browser was honest. Attestation can help filter out unknown keys, but built-in Safari and Chrome authenticators do not supply it, and requiring it in services such as Azure carries usability trade-offs. Rennich suggests treating the browser as part of the trust boundary, weighing attestation requirements against who can still sign in, and continuing to prefer FIDO over passwords.