Face à une attaque adversary-in-the-middle, le SMS-OTP n'apporte aucune protection. Le code arrive bien sur le téléphone de la victime, mais celle-ci le saisit sur une page relais qui le transmet au service légitime en quelques secondes. L'authentification réussit, et le cookie de session émis part chez l'attaquant. Le facteur a fonctionné comme prévu ; il a simplement authentifié la mauvaise personne.
Le canal hors bande ne protège pas d'un relais
L'argument historique en faveur du SMS repose sur la notion de canal hors bande : le code voyage par un chemin différent de celui de la connexion. Contre un attaquant qui écoute le réseau de la victime, cela avait un sens.
L'AiTM ne fait rien de tel. Il ne cherche pas à intercepter le canal de livraison : il attend que la victime lui apporte le code elle-même, sur la page qu'elle croit légitime. La séparation des canaux devient sans objet dès lors que les deux convergent dans le navigateur de la victime.
Trois propriétés du SMS-OTP le rendent totalement transparent pour ce type d'attaque :
- Le code est une valeur transmissible. Tout ce qui se recopie se relaie.
- Il n'est lié à aucun domaine. Rien dans le code ne dit pour quel site il a été émis.
- Il n'est lié à aucune opération. Il valide « une » authentification, pas « cette » authentification-là.
La latence du SMS aggrave même la situation
Détail contre-intuitif mais bien réel : la livraison d'un SMS n'est pas instantanée ni garantie. Les utilisateurs sont donc habitués aux codes qui tardent, aux renvois, aux « je n'ai rien reçu ».
Un attaquant exploite cette habitude. Sa page relais peut afficher « code non reçu ? demandez un nouvel envoi », ce qui lui donne autant de tentatives que nécessaire, sans éveiller le moindre soupçon. Une friction technique devient un outil de manipulation.
Ajoutons que la fenêtre de validité d'un code SMS est souvent généreuse — plusieurs minutes, pour absorber les délais réseau. Un proxy automatisé n'a besoin que de quelques secondes.
| Étape de l'attaque | Rôle du SMS-OTP | Effet réel |
|---|---|---|
| Vol du mot de passe sur la page relais | Aucun | L'attaquant n'en a pas besoin seul |
| Déclenchement du second facteur | Le code part vers la victime | Renforce la crédibilité de la page |
| Saisie du code par la victime | Le code est relayé | Aucun frein |
| Émission du cookie de session | Aucun | Le butin est constitué |
| Poursuite de la session | Aucun | Plus aucune authentification requise |
Ce que le SMS-OTP protège encore, et pour combien de temps
Soyons précis pour ne pas caricaturer. Le SMS-OTP conserve une utilité contre les attaques qui n'impliquent pas la victime en temps réel : bourrage d'identifiants, pulvérisation de mots de passe, réutilisation d'un mot de passe fuité. Sur ces scénarios automatisés, il bloque.
Mais il présente par ailleurs des faiblesses propres qui n'existent pas pour les autres méthodes : dépendance à un opérateur tiers, exposition au détournement de ligne, transit par des réseaux hors du contrôle de l'entreprise. C'est ce faisceau qui a conduit le NIST SP 800-63B à le classer « restricted », c'est-à-dire déconseillé.
Pour un RSSI, la question n'est donc pas « le SMS-OTP arrête-t-il l'AiTM ? » — la réponse est non — mais « quel est le coût de sa présence dans nos parcours sensibles ? ».
Les seules réponses efficaces contre l'AiTM
La liaison à l'origine. Avec FIDO2/WebAuthn, la réponse cryptographique est calculée pour un domaine donné. Un proxy hébergé ailleurs ne peut rien en faire. C'est la propriété qui casse le relais à la racine.
L'absence de secret transmissible. Aucun code affiché, aucune valeur à recopier : il n'y a plus rien à relayer.
La validation liée à l'action. Même en supposant l'authentification traversée, une opération sensible peut exiger une preuve fraîche, contextualisée, impossible à produire depuis une session volée. C'est l'angle de l'authentification cognitive : un challenge résolu au moment de l'acte, dans un canal éphémère ouvert par un QR code dynamique à usage unique.
La révocation des sessions. Puisque le butin d'un AiTM est le jeton, la capacité à l'invalider rapidement détermine l'ampleur réelle de l'incident.
Une trajectoire de sortie réaliste
- Inventorier les parcours où le SMS-OTP est encore présent, en distinguant connexion, validation d'opération et récupération de compte.
- Traiter la récupération en premier. C'est le chemin le plus attaqué et le plus souvent oublié.
- Basculer les comptes à privilèges vers une méthode liée à l'origine.
- Conserver temporairement le SMS en repli pour les populations sans alternative, mais jamais sur les opérations à impact financier.
- Mesurer la progression : part des comptes encore dépendants du SMS, trimestre après trimestre.
FAQ
Un code SMS à durée de validité très courte règle-t-il le problème ?
Non. Un proxy automatisé relaie le code en une fraction de seconde. Réduire la fenêtre gêne davantage les utilisateurs en zone de mauvaise couverture que les attaquants.
Afficher le nom du service dans le SMS aide-t-il ?
Marginalement. Cela peut alerter un utilisateur attentif si le service ne correspond pas à ce qu'il pensait faire, mais dans un scénario AiTM le service annoncé est le bon : c'est précisément l'authentification légitime qui est en cours.
Peut-on détecter l'AiTM côté serveur ?
Des signaux existent : caractéristiques réseau inhabituelles, incohérence entre le contexte d'authentification et le contexte d'usage ultérieur, connexion depuis une infrastructure d'hébergement. Ces signaux relèvent de l'analyse de risque, pas du facteur lui-même.
Que faire si l'on ne peut pas supprimer le SMS à court terme ?
Le cantonner : jamais sur les comptes d'administration, jamais comme voie de récupération, et toujours doublé d'une validation d'intention sur les opérations sensibles. C'est un palier, pas une cible.
Aller plus loin : le 4ᵉ facteur cognitif · MFA résistante au phishing · QR dynamique face à l'AiTM · le SMS-OTP est-il sûr ?