Multifactor authentication is evolving - time to catch up!
The multifactor authentication (MFA) most commonly used in organizations today is relying on smartphone applications that provide push notifications to be approved by employees when authenticating against protected resources. From Microsoft to Google authenticator, we're all used to this process now.
Yet this form of MFA has been under increased pressure from threat actors, who are now routinely trying to bypass it. There are 2 main attack vectors in the wild:
Prompt bombing or prompt fatigue attacks: a threat actor bombards a user with mobile application push notifications until the user either approves the request by accident or out of annoyance with the nonstop notifications.
Attacker in the middle proxy toolkits: phishing-as-a-service kits make it very easy to deploy attacks against MFA-enabled accounts in popular SaaS services. See an illustration of the attack here.
These attacks are successfully deployed against many organizations worldwide, so much so that Microsoft has recently introduced a workaround or mitigation method called number matching. This one is designed to thwart prompt bombing attacks, but will not help against attacker-in-the-middle toolkits.
Overall, it's becoming clear: to address these attacks, organizations will need to augment the defenses by introducing phishing resistant MFA. This is also now the clear recommendation in CISA's Guidance on phishing resistant MFA.
What is phishing resistant MFA?
One method is the old-school certificate based authentication (CBA), relying on public key cryptography and typically implemented with cards and card readers or USB tokens to be plugged into a laptop. However, CBA has never made it to be user friendly, even less mobile friendly. You might remember installing special software for the card reader or USB token to work properly. That would in turn cause all kinds of incompatibilities, especially if you were to use different authenticators. Soon you would need IT helpdesk specialists to make it work.
That's why a new authentication standard called FIDO2 has recently evolved that has quickly gained support from major platform providers (Microsoft, Android, Apple) and browser makers (Mozilla, Chrome, MS Edge, etc.). This makes the implementation far more easier and user friendlier when compared to traditional MFA based on certificates and PKI.
FIDO2 Authentication avoids the burden of administering a PKI infrastructure, but at the same time it's relying on strong public key cryptography. It provides 2 crucial anti-phishing measures:
Check that the user is authenticating against a valid application/web site, not a fake impersonator page. Each credential is bound to a resource or application (say, office.com), thwarting a phishing attempt using, say, fakeoffice.com to convince users to relay credentials (even MFA).
Check that the user is indeed physically present at the device from which authentication is initiated: far too many attacks rely on push notifications being initiated by an attacker, hoping the user will click that "Yes, that's me" button by mistake or out of annoyance. Fido2 token implementations always include a physical "gesture" proving the user's presence, effectively making it an additional authentication factor.
FIDO2 authenticators can either be:
separate physical tokens (called “roaming” authenticators) connected to a device via USB or near-field comms (NFC), or
embedded into laptops or smartphone devices as “platform” authenticators (for ex. supported by Windows OS Hello feature).
How to implement FIDO2 in an organizational context?
FIDO2 is gaining adoption fast, especially for consumer-facing banking apps used from mobile devices, where the applications are leveraging so-called platform authenticators built into, say, the iPhone or Android smartphones (called passkeys).
But what about the traditional organizational applications accessed by employees (from VPN to web e-mail access)? As seen above, these are now vulnerable to phishing even with MFA enabled: prompt bombing or attacker-in-the-middle attacks are becoming more common.
If you're using only Microsoft 365, some of the MFA strengthening is done automatically by Microsoft, such as the recent introduction of number matching (as mentioned earlier). Furthermore, Microsoft 365 is backed by Azure identity service, which recently announced some options for an easier FIDO2 adoption, should you want to play the Microsoft card only.
However, most organizations still have identities stored on-premise (Active Directory on-prem) and the complexities and realities of application usage are far from the neat Microsoft365-only scenario (think VPN, RDP, VDI, etc).
Asking from each application to support FIDO2 is a tall order. It turns out a much more pragmatic approach is to rely on identity federation: delegate authentication to an identity management service (IDaaS), relying mostly on federation protocols such as SAML or oAuth to connect existing apps.
That way, each individual entry point or application is no more forced to support FIDO2 individually, but rather all access is being checked by an IDaaS frontend which supports FIDO2 and other contextual checks or risk factors (such as geolocation or device checks), before allowing access.
This architecture is much more extendible and scalable, it supports the latest phishing resistant MFA, plus it supports a diverse set of access scenarios, typically found in organizations today.
FIDO2 promises a much simpler authentication experience for users and therefore a reduced TCO for organizations seeking to secure identities against phishing attacks. But in order to truly capitalize on this technology and thwart attackers, federated identity management covering all entry points is the way forward.