Migrer du SMS-OTP vers une application d'authentification (TOTP) est un progrès réel : la dépendance à un opérateur disparaît, le détournement de ligne aussi, et le code ne transite plus par un réseau tiers. Face à une attaque adversary-in-the-middle, ce progrès est pourtant sans effet : le code reste une valeur que la victime recopie sur une page relais, et que l'attaquant transmet en direct au service légitime.
Ce que le TOTP corrige vraiment
Il est utile de mesurer le gain avant d'en pointer la limite, car le TOTP répond effectivement à plusieurs faiblesses documentées du SMS.
- Aucune dépendance opérateur. Le détournement de carte SIM ne donne plus rien.
- Aucune livraison réseau. Le code est calculé localement, sans transiter par des infrastructures hors du contrôle de l'entreprise.
- Fonctionnement hors couverture. Utile en sous-sol, en zone blanche, à l'étranger.
- Coût nul par authentification. Argument non négligeable pour les grands parcs.
Ces bénéfices expliquent que le NIST SP 800-63B classe l'OTP par SMS et voix comme « restricted » sans appliquer le même traitement aux générateurs logiciels. Le TOTP est donc une amélioration défendable — à condition de savoir ce qu'elle ne couvre pas.
Le point aveugle : l'origine
Un code TOTP est le résultat d'un calcul entre un secret partagé et l'heure courante. Ce résultat ne contient aucune information sur le destinataire. Il ne sait pas s'il est saisi sur le site légitime ou sur une page relais hébergée à l'autre bout du monde.
Le déroulé d'un AiTM est alors mécanique :
- La victime arrive sur une page relais, généralement via un lien ciblé ou une recherche sponsorisée détournée.
- Elle saisit ses identifiants, que le proxy transmet en direct au service réel.
- Le service réclame le code TOTP ; le proxy affiche le même formulaire.
- La victime ouvre son application, lit le code, le saisit. Le proxy le relaie en une fraction de seconde.
- Le service émet un cookie de session, capturé par le proxy.
À aucun moment le code n'a été deviné, intercepté ou cassé. Il a été acheminé, par la victime elle-même.
| Faiblesse | SMS-OTP | TOTP | Facteur lié à l'origine |
|---|---|---|---|
| Détournement de ligne opérateur | Exposé | Non exposé | Non exposé |
| Interception sur réseau tiers | Exposé | Non exposé | Non exposé |
| Lecture sur écran verrouillé | Exposé | Selon la configuration | Non exposé |
| Extraction par téléphone (vishing) | Exposé | Exposé | Non exposé |
| Relais en temps réel (AiTM) | Exposé | Exposé | Non exposé |
| Vol du cookie après authentification | Exposé | Exposé | Exposé |
Les deux dernières lignes résument la situation : le TOTP corrige la colonne du transport, pas celle de la destination, et aucune méthode de connexion ne protège la session émise ensuite.
La fenêtre de validité n'est pas une protection
L'objection habituelle : « le code n'est valable que trente secondes ». Elle ne résiste pas à l'examen. Un proxy inverse fonctionne en automatique, sans intervention humaine côté attaquant. Le délai entre la saisie et le rejeu se compte en dizaines de millisecondes.
Pire, la plupart des serveurs acceptent le pas de temps précédent pour tolérer les décalages d'horloge, ce qui élargit encore la fenêtre. Réduire ces tolérances dégrade l'expérience utilisateur sans gêner l'attaquant.
Ce qu'il faut viser après le TOTP
Pour les comptes à privilèges : une méthode liée à l'origine. FIDO2/WebAuthn produit une réponse valide uniquement pour le domaine légitime. Un proxy hébergé ailleurs n'obtient rien d'exploitable. C'est la seule propriété qui neutralise le relais au moment de la connexion.
Pour les opérations sensibles : une preuve d'intention. Même une session obtenue frauduleusement ne doit pas suffire à déclencher un virement ou à modifier un accès. Le 4ᵉ facteur cognitif traite exactement ce niveau : un challenge résolu au moment de l'acte, dans un canal éphémère, sans secret réutilisable.
Pour tout le parc : la maîtrise des sessions. Durée de vie ajustée, révocation testée, surveillance des ruptures de contexte entre l'authentification et l'usage.
Ces trois axes se déploient progressivement. Conserver le TOTP sur les usages à faible enjeu pendant la bascule est une position tenable ; le conserver sur une console d'administration ne l'est plus.
FAQ
Le TOTP est-il malgré tout préférable au SMS-OTP ?
Oui, sur presque tous les critères hors AiTM : pas de dépendance opérateur, pas de détournement de ligne, pas de transit par un réseau tiers. C'est une étape intermédiaire pertinente, pas une destination.
Une notification push vaut-elle mieux qu'un TOTP contre l'AiTM ?
Non, les deux échouent, pour des raisons différentes. Le push est approuvé de bonne foi par la victime pendant que le proxy relaie l'échange ; le TOTP est recopié par elle. Le résultat est identique.
Comment repérer une session issue d'un relais ?
En comparant le contexte d'authentification et le contexte d'usage : adresse et empreinte du client différentes, géovélocité impossible, session utilisée depuis une infrastructure d'hébergement, ou modification de paramètres de sécurité juste après la connexion.
Faut-il attendre un projet global pour agir ?
Non. Basculer les administrateurs vers une méthode liée à l'origine et raccourcir la durée des sessions sensibles se réalisent sans refonte du socle d'identité, souvent en quelques semaines.
Aller plus loin : authentification cognitive : le principe · MFA résistante au phishing · QR dynamique contre l'AiTM · passkey, FIDO2 et WebAuthn