« Nous avons quitté le SMS pour une application d'authentification, nous sommes protégés contre le phishing. » Cette phrase, fréquente en comité, est fausse. Le TOTP supprime des faiblesses de transport, il ne rend pas le facteur résistant à l'hameçonnage. Le code s'affiche, se lit et se recopie — y compris sur une page frauduleuse.
Le mécanisme, sans indulgence
La page frauduleuse ne se contente plus de demander un identifiant et un mot de passe. Elle enchaîne, comme le service légitime, sur un champ « code de votre application ». L'utilisateur ouvre son application, lit six chiffres et les saisit.
Ce qui se passe ensuite dépend du niveau de l'attaquant :
- Attaque manuelle : il utilise le code lui-même dans la minute, sur le vrai service. La fenêtre est courte mais suffisante lorsque l'attaquant surveille sa campagne en direct.
- Attaque outillée : un relais transmet automatiquement le code au service légitime et récupère le cookie de session. C'est le mode dominant, et la victime aboutit même sur le vrai service, ce qui supprime tout signal d'anomalie.
Dans les deux cas, l'authentification a réussi côté service. Aucune alerte, aucun échec, aucune trace différenciante dans les journaux d'authentification.
Trois cibles souvent ignorées
Le code du jour n'est pas la seule chose qu'un attaquant peut hameçonner.
Les codes de secours. Lors de l'activation du TOTP, la plupart des services fournissent une liste de codes de récupération. Ils sont à usage unique mais sans limite de durée, souvent stockés dans un gestionnaire de fichiers, un carnet de notes ou un courriel envoyé à soi-même. Une page frauduleuse qui demande « un de vos codes de secours pour vérification » obtient un accès durable, indépendant du terminal.
L'enrôlement détourné. Un message invitant à « réenregistrer votre application d'authentification » conduit vers une page qui affiche un QR code fourni par l'attaquant. La victime enregistre alors dans son application un secret contrôlé par un tiers, ou fournit à l'attaquant le secret légitime affiché sur le service réel.
Le contexte de la validation. Un code TOTP ne dit rien de l'action qu'il autorise. Un attaquant qui déclenche une opération sensible pendant que la victime croit se connecter obtient la validation de cette opération.
| Cible | Ce que l'attaquant obtient | Durée d'exploitation | Contre-mesure |
|---|---|---|---|
| Code du moment | Une authentification | Quelques dizaines de secondes | Facteur lié à l'origine |
| Cookie de session émis | Un accès complet | Jusqu'à révocation | Sessions courtes, révocation |
| Code de secours | Un accès indépendant du terminal | Jusqu'à consommation | Stockage encadré, renouvellement |
| Secret d'enrôlement | Une génération illimitée de codes | Illimitée | Enrôlement vérifié, révocation |
| Validation d'opération | Une transaction autorisée | Immédiate | Preuve liée à l'action |
Pourquoi la formation ne referme pas cette porte
La consigne « vérifiez le nom de domaine » demande à un utilisateur d'analyser une chaîne de caractères, sur mobile, en situation de travail. Les techniques d'usurpation de domaine sont conçues précisément pour franchir cet examen.
Le raisonnement à retenir est simple : tout ce que l'utilisateur peut lire et recopier, il peut le recopier au mauvais endroit. La sensibilisation réduit la fréquence des erreurs ; elle ne change pas la nature du facteur.
Deux propriétés changent la nature du facteur. La liaison à l'origine de FIDO2/WebAuthn produit une réponse inexploitable hors du domaine légitime. La preuve d'intention associée à l'action, principe de l'authentification cognitive, fait qu'une validation obtenue hors contexte ne vaut rien : il n'y a pas de secret transmissible, et le challenge est résolu dans un canal éphémère lié à l'opération réelle.
Plan de durcissement sans changer de socle
- Traiter les codes de secours comme des identifiants privilégiés : génération limitée, stockage encadré, renouvellement après tout incident, alerte lors de leur utilisation.
- Verrouiller l'enrôlement : tout enregistrement d'un nouveau facteur exige une réauthentification et déclenche une notification par un canal indépendant.
- Basculer les comptes à privilèges vers une méthode liée à l'origine, en priorité les administrateurs de l'annuaire et des services de messagerie.
- Réduire la valeur de la session : durée courte sur les périmètres sensibles, révocation testée, surveillance des ruptures de contexte.
- Ajouter une validation d'intention sur les opérations à impact — paiement, changement de coordonnées bancaires, ouverture d'accès — indépendante de la session en cours.
- Instrumenter la détection post-authentification, seule voie possible puisque l'authentification elle-même paraît normale : création de règles de messagerie, enregistrement de facteur, export inhabituel.
FAQ
Le TOTP est-il inutile alors ?
Non. Il bloque la réutilisation d'un mot de passe volé, le bourrage d'identifiants et le détournement de ligne téléphonique. Il ne doit simplement pas être présenté comme une protection contre l'hameçonnage.
Une application avec vérification biométrique à l'ouverture change-t-elle la donne ?
Elle protège le terminal contre un accès physique non autorisé, ce qui est utile. Elle ne modifie pas le fait que le code, une fois affiché, est recopiable sur une page frauduleuse.
Faut-il supprimer les codes de secours ?
Ils restent nécessaires, mais doivent être traités comme des accès de dernier recours : nombre limité, stockage encadré, alerte systématique à l'usage, et régénération après tout événement suspect.
Comment savoir si un utilisateur a été hameçonné avec succès ?
L'authentification étant valide, cherchez les conséquences : nouveau facteur enrôlé, règle de transfert de messagerie, session active depuis un contexte inhabituel, ou action sensible réalisée peu après la connexion.
Aller plus loin : le facteur cognitif expliqué · MFA résistante au phishing · le QR dynamique contre le phishing · vol de session après authentification