Skip to content

Qu'est-ce qui rend la MFA « résistante au hameçonnage », et comment FIDO2/passkeys y parviennent ?

Réponse courte

La MFA résistante au hameçonnage signifie que le second facteur ne peut pas être rejoué contre le vrai site même si l'utilisateur est trompé. Les passkeys FIDO2/WebAuthn y parviennent grâce à une cryptographie à clé publique liée à l'origine : l'authentificateur signe un défi lié au domaine du vrai site, de sorte qu'un identifiant capturé par un site sosie ou un attaquant-au-milieu est inutile. Les codes TOTP et les invites par notification restent hameçonnables car ils peuvent être relayés en temps réel.

Toutes les MFA ne se valent pas. La norme sur laquelle on vous interrogera est la résistance au hameçonnage : le second facteur survit-il à un utilisateur amené à se connecter sur une page falsifiée ou proxifiée ?

Pourquoi la MFA courante reste hameçonnable

  • Les codes TOTP (applications d'authentification) et les codes SMS ne sont que des secrets que l'utilisateur saisit. Un kit de hameçonnage attaquant-au-milieu (AiTM) montre à l'utilisateur une réplique parfaite de la page de connexion, capture tout ce qu'il saisit — y compris le code en direct — et le relaie instantanément vers le vrai site. Le code fonctionne car il n'est pas lié à l'endroit où il est utilisé.
  • Les approbations par notification sont vulnérables au même relais plus à la « fatigue MFA », où l'attaquant inonde de demandes jusqu'à ce que l'utilisateur approuve.

Dans tous ces cas, l'identifiant est portable : il n'a aucune idée du site contre lequel il est réellement utilisé.

Comment FIDO2/WebAuthn corrige cela

FIDO2 (la pile protocolaire derrière les passkeys et WebAuthn) utilise une cryptographie à clé publique liée à l'origine. À l'enregistrement, l'authentificateur (clé de sécurité, téléphone ou TPM de la plateforme) génère une paire de clés limitée au domaine du vrai site et ne donne au site que la clé publique. À la connexion, le site envoie un défi ; l'authentificateur le signe uniquement si l'origine demandeuse correspond à celle pour laquelle la clé a été enregistrée, et la clé privée ne quitte jamais l'appareil.

Ainsi, quand un utilisateur atterrit sur paypa1-login.com, le navigateur/authentificateur voit que l'origine ne correspond pas et refuse de signer. Il n'y a aucun code à saisir, rien à relayer, et rien que le proxy AiTM puisse capturer et réutiliser.

Variantes de passkeys

Les passkeys existent liées à l'appareil (la clé privée ne quitte jamais un authentificateur matériel unique — le plus fort) ou synchronisées via un trousseau cloud (plus pratique, mais la confiance se déplace vers le fournisseur du trousseau). L'une comme l'autre est radicalement meilleure que les codes.

Ce que recherchent les recruteurs : vous expliquez que le relais AiTM déjoue les codes/notifications, et vous savez articuler la liaison à l'origine et le fait que la clé privée ne quitte jamais l'appareil comme les mécanismes qui rendent FIDO2 résistant au hameçonnage.

Questions de suivi probables

  • Comment un proxy attaquant-au-milieu (AiTM) déjoue-t-il le TOTP et la MFA par notification ?
  • Quelle est la différence entre une passkey synchronisée et une passkey liée à l'appareil ?
  • Quel rôle joue la vérification de l'« origine » WebAuthn ?

Sources

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.