Au-delà des mots de passe : la MFA résistante au phishing

L'authentification multifacteur n'est pas un bloc unique. L'écart entre un code à usage unique envoyé par SMS et une passkey adossée au matériel, c'est la différence entre ralentir un attaquant et l'arrêter net. C'est toute la distinction entre une MFA hameçonnable et une MFA résistante au phishing.

Pourquoi la plupart des MFA restent hameçonnables

Le problème des codes et des notifications push, c'est que le second facteur est un secret partagé que l'humain peut transmettre. Si un utilisateur peut lire un code et le saisir sur une page, on peut le tromper pour qu'il le saisisse sur la page d'un attaquant.

• Codes SMS / TOTP — un proxy d'attaquant au milieu (AiTM) comme Evilginx présente un clone de connexion au pixel près, relaie en temps réel les identifiants et le code à usage unique, puis capture le cookie de session obtenu. Le code valide n'apporte aucune protection.
• Notifications push — vulnérables à la fatigue MFA / bombardement de requêtes : des approbations répétées jusqu'à ce qu'un utilisateur lassé appuie sur « Approuver ».
• Échange de SIM (SIM swapping) — transfère le numéro de la victime vers la SIM de l'attaquant, ce qui neutralise entièrement le SMS.

La correspondance de numéro et le contexte géographique sur le push aident, mais ce sont des atténuations posées sur une conception fondamentalement hameçonnable.

Ce qui rend une MFA résistante au phishing

La MFA résistante au phishing retire l'humain de la décision de confiance. Deux propriétés comptent :

• Liaison à l'origine — l'identifiant est cryptographiquement lié à l'origine web exacte pour laquelle il a été enregistré. Un domaine ressemblant ou un proxy ne correspond tout simplement pas, et l'authentification échoue silencieusement.
• Aucun secret partagé en transit — l'authentification repose sur un défi-réponse avec une clé privée qui ne quitte jamais l'appareil.

Les standards qui offrent cela :

• FIDO2 / WebAuthn — le standard navigateur et plateforme pour l'authentification à clé publique.
• Passkeys — des identifiants FIDO2, soit liés à l'appareil (clé de sécurité matérielle, ex. YubiKey), soit synchronisés (sauvegardés dans un écosystème comme Apple, Google ou un gestionnaire de mots de passe).
• PIV / cartes à puce (x.509) — l'approche historique en entreprise et dans le secteur public.

Pourquoi les proxys AiTM échouent face à elle

Utilisateur → phish.example (proxy attaquant) → real.example

L'assertion WebAuthn est signée sur l'origine vue par le navigateur :
  clientDataJSON.origin = "https://phish.example"
L'identifiant a été enregistré pour "https://real.example"
→ origine non concordante → l'authentificateur/RP rejette l'assertion

Il n'y a aucun code que l'utilisateur puisse relayer et aucun cookie que le proxy puisse récolter, car la connexion ne réussit jamais contre la mauvaise origine. C'est le navigateur qui l'impose — pas l'humain.

Déployer sans tout casser

Prioriser par le risque. Commencez par les administrateurs, la finance, les dirigeants et toute personne ayant accès aux systèmes critiques. Ce sont les comptes que les kits AiTM visent en premier.

Anticiper la récupération de compte. La récupération est le nouveau point faible : si la perte d'une clé retombe sur un SMS ou un appel au support, vous avez réintroduit le chemin hameçonnable. Exigez deux authentificateurs enregistrés par utilisateur (par exemple une clé de sécurité et une passkey de plateforme) et durcissez la vérification d'identité au support.

Gérer les parcs hétérogènes. Les passkeys synchronisées facilitent le déploiement sur les appareils personnels et mobiles ; les clés liées à l'appareil conviennent aux scénarios de haute assurance et aux postes partagés/kiosques. Beaucoup d'organisations combinent les deux.

Séquencer la migration :

1. Activer FIDO2/passkeys à côté de la MFA existante.
2. Faire enregistrer un second facteur et mener des campagnes d'inscription.
3. Passer les rôles privilégiés en résistant au phishing obligatoire.
4. Retirer le SMS et la voix comme facteurs.
5. Étendre l'exigence de résistance au phishing à toute l'organisation via l'accès conditionnel.

Visez une MFA résistante au phishing obligatoire, et pas seulement disponible. Tant qu'un repli hameçonnable existe, les attaquants y dirigeront les utilisateurs — une technique dite de rétrogradation de la MFA.

Comment GottaPhish aide

Une MFA hameçonnable — par code ou par push — donne un faux sentiment de sécurité tout en laissant une faille réelle que les attaquants exploitent activement ; posséder la technologie ne suffit pas à la combler. GottaPhish et son équipe d'experts vous aident à bâtir l'argumentaire et à mener le déploiement : nos simulations de type AiTM démontrent, de façon sûre et mesurable, comment la MFA par code ou par push tombe face à un vrai proxy, donnant à la direction la preuve pour financer une MFA résistante au phishing. Ensuite, nos experts accompagnent concrètement votre déploiement FIDO2/passkeys — priorisation des rôles à risque, planification de l'inscription à double authentificateur et de la récupération, suivi de l'adoption aux côtés de vos taux de clic et de signalement — et vous aident à interpréter les résultats pour prouver que l'écart hameçonnable se referme réellement.