Entre un code généré par application (TOTP) et un code reçu par message (SMS-OTP), le choix est tranché : le TOTP est préférable sur presque tous les critères, et le NIST SP 800-63B classe l'OTP transmis par SMS ou par appel vocal comme restricted, c'est-à-dire déconseillé. Mais cette comparaison a une limite : les deux transmettent une valeur, et tout ce qui se transmet peut se relayer.
Deux mécaniques très différentes
TOTP (Time-based One-Time Password, RFC 6238) repose sur un secret partagé établi une fois pour toutes lors de l'enrôlement — le QR code que l'on scanne. À chaque affichage, l'application calcule une empreinte cryptographique de ce secret combiné à l'heure courante, découpée en général en tranches de trente secondes, puis en extrait six à huit chiffres. Le serveur effectue le même calcul de son côté et compare. Aucune donnée ne circule au moment de la génération : le code peut être produit hors ligne, en mode avion.
SMS-OTP repose sur un canal de transport. Le serveur tire un code aléatoire, le stocke, puis le confie au réseau de l'opérateur, qui l'achemine vers un numéro. La sécurité ne dépend plus d'un calcul cryptographique mais de la capacité de la chaîne télécom à délivrer le message à la bonne personne — chaîne sur laquelle l'entreprise n'a aucune maîtrise.
Comparaison sur les critères qui décident
| Critère | TOTP | SMS-OTP |
|---|---|---|
| Dépendance réseau à l'usage | aucune (calcul local) | opérateur, itinérance, couverture |
| Détournement de la ligne | sans objet | SIM swapping, portabilité frauduleuse |
| Interception en transit | sans objet | signalisation télécom, aperçu sur écran verrouillé |
| Secret côté serveur | oui, une graine par utilisateur à protéger | non, code éphémère |
| Relais en temps réel | vulnérable | vulnérable |
| Coût unitaire | nul après déploiement | coût par message, variable selon les pays |
| Sauvegarde et migration | délicate si l'application est perdue | liée au numéro, donc plus simple |
| Position du NIST SP 800-63B | recevable | restricted |
| Accessibilité | nécessite un smartphone ou un jeton dédié | fonctionne sur tout téléphone |
Deux enseignements. D'abord, le SMS accumule des risques que le TOTP n'a pas : le SIM swapping — obtention frauduleuse d'une carte SIM auprès de l'opérateur — suffit à capter tous les codes d'une personne sans jamais toucher à son téléphone. Ensuite, le TOTP introduit un risque propre : le stock de graines côté serveur. Une base de secrets partagés compromise permet de générer des codes valides pour l'ensemble des comptes ; elle mérite le même traitement qu'un coffre de clés.
La faiblesse que les deux partagent
C'est le point que la comparaison classique manque. TOTP et SMS-OTP produisent tous deux une valeur que l'utilisateur recopie. Or un attaquant n'a pas besoin de casser la cryptographie : il lui suffit de se placer entre l'utilisateur et le service, avec un proxy inverse, et de faire transiter la saisie en direct.
Le déroulé est toujours le même : l'utilisateur atterrit sur une page qui ressemble au service, saisit son identifiant, puis son code à six chiffres ; le relais transmet le tout au vrai site dans la même seconde et récupère le cookie de session émis en retour. Trente secondes de validité, c'est largement suffisant pour un script automatisé.
Deux conséquences pratiques :
- La durée de vie du code n'est pas une protection. Réduire la fenêtre de validité gêne l'attaquant humain, pas l'attaquant outillé.
- La comparaison TOTP/SMS reste une comparaison entre deux options rejouables. Passer du SMS au TOTP est un progrès net, ce n'est pas une réponse au phishing moderne.
Ce que ni l'un ni l'autre ne fait, c'est lier la preuve au domaine visité — ce que fait FIDO2/WebAuthn grâce à la liaison à l'origine — ni lier la preuve à l'action demandée, ce que vise le facteur cognitif avec un challenge résolu au moment de l'opération, sans secret réutilisable.
Quelle décision prendre
Une trajectoire réaliste, dans l'ordre :
- Sortir du SMS-OTP sur les parcours sensibles. Administration, finances, ressources humaines, accès distants : ce sont les périmètres où le détournement de ligne coûte le plus cher.
- Basculer le reste vers le TOTP lorsque la sortie complète des codes n'est pas encore possible : c'est une amélioration immédiate, à coût faible.
- Conserver le SMS uniquement en repli documenté, jamais comme méthode principale sur une opération à impact.
- Traiter les administrateurs séparément, avec une méthode non rejouable : cette population concentre l'essentiel de la valeur pour un attaquant.
- Vérifier la récupération de compte. Une chaîne TOTP dont la réinitialisation passe par un SMS vaut, pour l'attaquant, la sécurité du SMS.
FAQ
Le TOTP est-il vraiment vulnérable au phishing ?
Oui. Il protège contre la réutilisation d'un mot de passe volé et contre les attaques hors ligne, mais pas contre un relais en temps réel. Un proxy inverse capte le code et l'utilise avant son expiration.
Pourquoi le NIST déconseille-t-il le SMS ?
Parce que le canal de transport échappe au contrôle du service : la ligne peut être détournée auprès de l'opérateur, le message intercepté dans la chaîne de signalisation ou lu sur un écran verrouillé. Le classement restricted invite à documenter le risque et à prévoir une alternative.
Faut-il supprimer le SMS immédiatement partout ?
Rarement possible d'un coup, notamment sur les parcours grand public où il reste le seul canal universel. La priorisation par criticité — parcours sensibles d'abord, puis le reste — donne de meilleurs résultats qu'un arrêt brutal mal préparé.
Comment protéger les graines TOTP côté serveur ?
Comme des clés : stockage chiffré, accès restreint et journalisé, séparation des environnements, procédure de rotation en cas de suspicion. Une fuite de graines est équivalente à une fuite de seconds facteurs pour l'ensemble du parc.
Aller plus loin : remplacer les codes par une preuve d'intention · 2FA ou MFA · SMS-OTP face au SIM swapping · MFA résistante au phishing