Passkey Redaction and the Impact to Organizations

Recently, eSentire published some interesting research on successfully phishing users even when they’ve configured phishing resistant MFA (like a FIDO2 Passkey or a smart card). For organizations deploying Phishing Resistant MFA (PR-MFA), like a FIDO2 Passkey, be it for internal user authentication or customer logon, there are some important takeaways.

First off, some have mischaracterized this as a weakness in passkeys, it is not. It is a weakness in how some (many?) organizations implement passkeys. How so?

The classic phrase applies, a chain is only as strong as its weakest link. If a user can authenticate using PR-MFA and non-PR-MFA, then they are vulnerable to phishing. There are plenty of examples of similar styled attacks, from SSL Stripping to socially engineering helpdesk/customer support agents. If the default authentication method is too difficult for an attacker, they’ll try alternative/backup methods. Passkey Redaction “hides” the Passkey authentication option on logon screens, forcing users to authenticate using a non-PR-MFA method. Since this “redacted” page is a phishing site, the result is full account access for the attacker. So, what should an organization do?

Getting started on the PR-MFA journey can be daunting. Far too many services today still rely on less-secure MFA. The inevitable part of a PR-MFA journey is to (eventually) disable all legacy MFA options. But that’s a bit scary, especially for consumer-facing services. Some options: 1: Identify the most sensitive users and target them for mandatory PR-MFA access. For example, sysadmins with high-level privileges, executives with access to highly sensitive data, or customers with high-value accounts.
2: Allow users to opt-in to stronger security. Though many sensitive users can be determined programmatically, that might not catch everyone. Plus, some users have higher security awareness than others, so they may prefer living with the additional pain of higher security. 3: Ensure any account recovery option involves multiple safeguards. One real-world example: An organization sends a boring SMS as the failback for passkeys. No mention in the SMS that passkey logon has been bypassed nor an automated email notification. To a user, they might presume some technical glitch has blocked passkey logon. If PR-MFA is going to be enforced, expect attackers will go after the account recovery process; make sure a lot of thought is put into protecting that as well.

Last important note. Some services only allow 1-2 passkeys. That’s way too low, a limit of 5-10 is better. Why? Users should be encouraged to setup backup passkeys. For example, a combination of physical keys and device-bound and roaming passkeys. For a user worried about losing a device, that can easily require 3-5 passkey slots. Added bonus, the more passkeys a user has, the less likely they are to need account recovery.

Standard disclaimer: All opinions/views are my own.

This post originally appeared on Mastodon.