L’authentification multifacteur : limites et contournements classiques
L’authentification multifacteur (MFA) ajoute une seconde preuve d’identité au mot de passe : un code, une application, une clé physique. C’est l’une des mesures les plus efficaces qui existent, et les autorités comme l’ANSSI la recommandent. Mais « efficace » ne veut pas dire « infaillible ». Un bon auditeur sait où elle peut être mal mise en œuvre ou contournée, pour que les équipes la corrigent. Voyons cela sans jamais perdre de vue notre cadre : l’entraînement.
Rappel légal
Contourner un second facteur sur un compte qui n’est pas le vôtre ou sur un service que vous n’êtes pas autorisé à tester relève des articles 323-1 à 323-3-1 du Code pénal. Cette leçon décrit des principes pour comprendre et corriger, pas une procédure à appliquer ailleurs que dans votre laboratoire ou une plateforme d’entraînement légale.
Rappel : les facteurs d’authentification
On distingue trois catégories : ce que l’on sait (mot de passe), ce que l’on possède (téléphone, clé de sécurité), ce que l’on est (biométrie). La MFA combine au moins deux catégories différentes. Deux mots de passe ne font pas une MFA.
| Méthode | Force | Limite principale |
|---|---|---|
| Code par SMS | Simple, répandue | Dépend du réseau téléphonique et peut être détournée (par exemple par transfert frauduleux du numéro) |
| Code d’application (TOTP) | Fonctionne hors réseau, codes temporaires | Peut être saisi sur un faux site et retransmis |
| Notification « approuver » | Pratique | Sensible à la lassitude : l’utilisateur finit par accepter |
| Clé de sécurité physique (FIDO2) | Liée au vrai site, très résistante à l’hameçonnage | Coût, risque de perte, mise en place d’une solution de secours |
Où la MFA peut être défaillante : côté application
Dans un test web, on s’intéresse à la mise en œuvre. Voici les familles de défauts, du point de vue de la conception :
Une vérification qui n’est pas imposée côté serveur
Le serveur doit refuser l’accès tant que le second facteur n’est pas validé. Un défaut classique : l’étape du second facteur existe dans l’interface, mais le serveur considère l’utilisateur comme authentifié dès la première étape. Il suffirait alors d’aller directement à une page protégée sans passer par le second écran. Test : après avoir saisi uniquement le mot de passe sur votre compte de test, essayez d’accéder à une page réservée en la demandant directement. Elle doit être refusée.
Une décision laissée au client
Si la réussite de l’étape 2 est signalée par une valeur que le client peut modifier (un paramètre, un champ masqué, un cookie non signé), l’application fait confiance à ce que l’utilisateur contrôle. Le résultat d’une vérification doit rester dans l’état de session côté serveur.
Un code qui peut être deviné
Un code à six chiffres n’offre qu’un million de possibilités. Sans limitation du nombre d’essais, il peut être testé. L’application doit limiter les essais par session et par compte, et invalider le code après quelques échecs. Test en laboratoire : quelques échecs volontaires, puis observation d’un blocage ou non.
Un code qui reste valable trop longtemps ou qui est réutilisable
Un code temporaire doit expirer rapidement et ne servir qu’une fois. Test : demandez un code, laissez passer un délai, vérifiez qu’il est refusé ; utilisez-le une fois, puis réessayez.
Des chemins alternatifs plus faibles
Une application peut protéger la connexion par MFA mais laisser, par exemple, l’interface mobile, une ancienne API ou le formulaire de récupération sans second facteur. La solidité d’une chaîne est celle de son maillon le plus faible : inventoriez tous les moyens d’obtenir une session (votre carte du chapitre 1 est précieuse ici).
La récupération du second facteur
Que se passe-t-il quand on perd son téléphone ? Si le contournement se résume à répondre à une question facile ou à cliquer sur un lien envoyé à une adresse e-mail faiblement protégée, le second facteur n’a pas de valeur. Les codes de secours doivent être générés aléatoirement, stockés comme des mots de passe, à usage unique et, de préférence, régénérés après usage.
Où la MFA peut être défaillante : côté humain
Même une application parfaitement conçue peut être contournée en jouant sur les personnes. Les attaquants réels utilisent surtout ces voies, que vous connaissez par le cours d’introduction :
- L’hameçonnage en temps réel : un faux site relaie à la volée le mot de passe et le code que l’utilisateur saisit, puis les rejoue sur le vrai site. Les codes classiques n’y résistent pas ; les clés FIDO2, liées au nom de domaine réel, si.
- La fatigue de notifications : l’attaquant, qui connaît le mot de passe, déclenche des demandes d’approbation à répétition jusqu’à ce que la victime, excédée, accepte.
- Le détournement de numéro de téléphone : pour les codes par SMS.
- Le vol de session après authentification : si le cookie de session est volé (voir leçon 2), le second facteur a déjà été franchi par la victime.
Ces constats ne remettent pas en cause l’intérêt de la MFA, mais ils expliquent pourquoi l’on recommande les méthodes résistantes à l’hameçonnage pour les comptes sensibles et la formation des utilisateurs en complément.
Les bonnes pratiques à recommander
- Imposer la vérification du second facteur côté serveur, pour tous les chemins d’accès.
- Limiter les essais et faire expirer rapidement les codes.
- Proposer des méthodes résistantes à l’hameçonnage (clés de sécurité, passkeys) pour les comptes à privilèges.
- Limiter les demandes d’approbation répétées et ajouter un contexte à la notification (lieu, appareil, nombre à confirmer).
- Sécuriser la récupération au même niveau que la connexion.
- Notifier l’utilisateur quand un second facteur est ajouté, retiré ou modifié.
- Régénérer l’identifiant de session après validation du second facteur.
Astuce
Dans un rapport, évitez la formule « la MFA est contournable » : elle est vague et alarmiste. Écrivez précisément quel défaut vous avez observé (« la page /espace-client est accessible sans validation du second facteur ») et dans quelles conditions.
À vous de jouer
Sans attaquer quoi que ce soit, construisez une grille d’audit de la MFA pour un service imaginaire de votre choix.
- Listez cinq contrôles à effectuer côté serveur (par exemple : accès direct à une page protégée, limitation des essais, expiration du code…).
- Pour chacun, indiquez comment vous le vérifieriez dans un laboratoire, et le résultat attendu.
- Ajoutez deux risques « côté humain » avec une mesure de réduction pour chacun.
Voir une solution
Exemple de grille : (1) accès direct à une page protégée après la première étape : doit être refusé ; (2) cinq échecs de code : blocage ou ralentissement ; (3) code utilisé une fois puis rejoué : refus ; (4) code expiré : refus ; (5) autre canal (application mobile, ancienne interface) : second facteur exigé aussi. Risques humains : hameçonnage en temps réel (mesure : clés FIDO2 ou passkeys pour les comptes sensibles, sensibilisation) ; fatigue de notifications (mesure : limiter le nombre de demandes, afficher un contexte et demander de saisir un nombre affiché à l’écran).
À retenir
- La MFA est très efficace, mais sa solidité dépend de sa mise en œuvre.
- Côté application : vérification imposée par le serveur, essais limités, codes courts et à usage unique, chemins alternatifs protégés, récupération sécurisée.
- Côté humain : hameçonnage en temps réel, fatigue de notifications, détournement de numéro, vol de session.
- Les clés FIDO2 et les passkeys résistent à l’hameçonnage.
- Un constat précis vaut mieux qu’une affirmation générale.
Vous avez parcouru les failles d’authentification : mots de passe, sessions, récupération, second facteur. Le chapitre suivant s’intéresse à ce qui se passe quand l’application traite les données que vous lui envoyez : les injections.