Un code TOTP à six chiffres est court. Sa résistance au brute force ne vient donc pas de sa longueur mais du vérificateur : le serveur doit plafonner les tentatives, invalider un code consommé et limiter la tolérance de décalage d'horloge. Quand ces trois contrôles sont en place, la force brute n'est pas une voie d'attaque réaliste. Quand l'un manque, elle le redevient immédiatement.
Le calcul que fait l'attaquant
L'espace de recherche d'un code à six chiffres est modeste, et l'attaquant dispose d'une durée non négligeable : le pas de temps courant, généralement trente secondes, souvent élargi par la tolérance de décalage acceptée par le serveur.
Trois paramètres déterminent entièrement la faisabilité :
- Le nombre de tentatives autorisées par compte et par fenêtre.
- La granularité du plafond : par compte seulement, ou aussi par origine réseau ? Un attaquant qui teste un code fixe sur des milliers de comptes contourne un plafond exclusivement par compte.
- La largeur de la fenêtre acceptée : accepter plusieurs pas de temps de part et d'autre multiplie mécaniquement le nombre de codes valides à un instant donné.
Le plus souvent, ce n'est pas le TOTP qui est en cause, mais son intégration dans une application maison, un portail ancien ou une brique développée à part du fournisseur d'identité.
| Paramètre | Configuration risquée | Configuration attendue |
|---|---|---|
| Tentatives par compte | Illimitées ou remise à zéro à chaque saisie | Plafond strict, verrouillage progressif |
| Tentatives par origine | Non contrôlées | Limitation par adresse et par empreinte de client |
| Code déjà consommé | Accepté à nouveau dans la fenêtre | Invalidé dès la première acceptation |
| Tolérance de décalage | Plusieurs minutes | Un pas de temps de part et d'autre au maximum |
| Journalisation des échecs | Absente ou non alertée | Alerte sur rafales et sur motifs distribués |
| Verrouillage | Sans notification | Notification à l'utilisateur et à la supervision |
L'attaque distribuée : le vrai scénario
Le brute force naïf — mille tentatives sur un compte — est bloqué par n'importe quel plafond correct. Le scénario réaliste est l'inverse : peu de tentatives, beaucoup de comptes.
L'attaquant dispose déjà d'identifiants valides, issus de fuites ou d'un hameçonnage antérieur. Il teste alors quelques codes sur chacun des comptes de sa liste, en variant les origines réseau. Sur un parc de plusieurs milliers de comptes, la probabilité d'aboutir sur au moins un devient non négligeable, alors même qu'aucun compte pris isolément ne dépasse son plafond.
La contre-mesure ne relève plus du compte, mais de la corrélation globale : suivre le taux d'échecs de second facteur à l'échelle du parc, et non compte par compte. C'est une règle de détection simple à écrire et rarement présente.
Le secret partagé, cible plus rentable que le code
Un attaquant sérieux ne devine pas un code : il cherche la graine, c'est-à-dire le secret partagé enregistré lors de l'enrôlement. Trois expositions sont classiques.
La capture au moment de l'enrôlement. Le QR code affiché à l'écran contient le secret. Une capture d'écran conservée, un partage d'écran en visioconférence ou un document d'onboarding archivé suffisent à le compromettre durablement.
La sauvegarde de l'application d'authentification. De nombreuses applications proposent une synchronisation entre appareils. Le secret quitte alors le terminal et sa protection dépend d'un autre compte, souvent protégé plus faiblement.
Le stockage côté serveur. Le vérificateur doit conserver les secrets de tous les utilisateurs. Cette base est une cible de choix : sa compromission livre la capacité de générer les codes de l'ensemble du parc, sans laisser de trace côté utilisateur.
Cette dernière propriété distingue nettement le TOTP des méthodes à clé asymétrique, où le vérificateur ne détient qu'une clé publique — inutile à un attaquant.
Contrôles à mettre en place
- Vérifier les plafonds sur chaque point d'entrée, y compris les portails secondaires, les API et les applications anciennes. Le maillon faible est rarement le portail principal.
- Ajouter une détection globale sur les échecs de second facteur à l'échelle du parc, avec seuil sur la fenêtre glissante.
- Réduire la tolérance de décalage au strict nécessaire et invalider tout code consommé.
- Sécuriser l'enrôlement : QR affiché une seule fois, interdiction de capture dans les procédures internes, révocation du secret en cas de doute.
- Encadrer la synchronisation des applications d'authentification pour les populations sensibles.
- Protéger et cloisonner la base de secrets, avec surveillance des accès en lecture.
Ces contrôles rendent le brute force impraticable. Ils ne changent rien au fait que le TOTP reste un secret partagé, recopiable par la victime sur une page frauduleuse. Une méthode sans secret partagé — clé asymétrique liée à l'origine, ou preuve d'intention comme celle du facteur cognitif — supprime à la fois la base de secrets à protéger et la valeur d'un code deviné.
FAQ
Faut-il passer à des codes à huit chiffres ?
Le gain est marginal si les plafonds sont corrects, et nul contre le phishing. Mieux vaut investir l'effort dans la limitation des tentatives et la corrélation globale que dans l'allongement du code.
Le verrouillage de compte n'ouvre-t-il pas un risque de déni de service ?
Si, d'où l'intérêt d'un verrouillage progressif et temporaire, associé à une limitation par origine. Un blocage définitif déclenchable par un tiers devient lui-même une vulnérabilité exploitable.
Comment détecter une attaque distribuée en cours ?
En suivant le ratio d'échecs de second facteur à l'échelle du parc, la dispersion des comptes visés et la concentration des origines. Un taux inhabituel réparti sur de nombreux comptes est plus révélateur qu'une rafale sur un compte unique.
Que faire si une graine TOTP a pu être exposée ?
Révoquer le facteur et procéder à un nouvel enrôlement dans un contexte vérifié. Un secret partagé compromis reste exploitable indéfiniment, sans aucun signal visible pour l'utilisateur.
Aller plus loin : le 4ᵉ facteur cognitif · polymorphisme contre le brute force · MFA résistante au phishing · TOTP pour l'accès distant