Six chiffres calculés sur ton téléphone, jamais envoyés nulle part, valables trente secondes.
On ouvre une application, on lit six chiffres, on les recopie. Aucun message n'est arrivé. Le téléphone était en mode avion et les chiffres se sont affichés quand même, exacts. C'est le point qui étonne au premier usage, et il contient toute la propriété du facteur : le code n'a pas voyagé, il a été calculé des deux côtés en même temps.
Ce détail retire d'un coup l'opérateur mobile, le réseau et la boîte email de la chaîne d'attaque. Il en laisse d'autres intacts, et c'est là que le sujet devient intéressant.
D'où ça vient
En 2004, l'authentification forte appartient à un fournisseur et à son jeton matériel propriétaire. Un consortium se monte pour ouvrir le format : l'Initiative for Open Authentication, ou OATH, qui rassemble des acteurs comme VeriSign, IBM ou ActivCard.
Le premier résultat est la RFC 4226, publiée en décembre 2005, qui définit HOTP. Le principe : un secret partagé une seule fois entre le service et l'appareil, un compteur qui s'incrémente à chaque usage, et une fonction HMAC qui transforme le couple en six chiffres. Personne n'envoie le secret, chacun calcule de son côté.
Le compteur pose un problème pratique. Si l'appareil génère un code sans que le service le voie, les deux compteurs divergent, et il faut des fenêtres de rattrapage. La RFC 6238, publiée en mai 2011, remplace le compteur par l'horloge : le facteur mobile devient le temps découpé en tranches de 30 secondes. Les deux côtés partagent une horloge sans se parler. C'est TOTP.
Entre les deux, Google publie Google Authenticator le 20 septembre 2010, avec un code source d'abord ouvert. L'application fait deux choses décisives : elle range plusieurs comptes dans un seul écran, et elle inscrit le secret d'enrôlement dans un QR code que n'importe quel service peut afficher. L'enrôlement passe de quelques minutes de saisie à trois secondes de caméra. Le format se répand chez tout le monde parce qu'il est ouvert, gratuit et interopérable.
Le problème que ça résout
Rien ne transite. Cette phrase courte retire beaucoup de monde de la chaîne.
Pas d'opérateur mobile, donc aucun détournement de ligne possible. Le simulateur compte cette technique à 0,25 pour un attaquant ciblé sur un obstacle SMS, et à zéro sur un code temporaire. Pas de réseau de signalisation, donc pas d'interception à la SS7. Pas de boîte email dans la boucle, donc la prise de contrôle de la boîte, qui vaut 0,55 pour un attaquant ciblé quand la boîte est faible, ne franchit pas cet obstacle.
Contre le rejeu d'identifiants fuités, le code temporaire fait le même travail que le code par SMS : le script détient la paire, pas le secret d'enrôlement, il s'arrête.
Contre la fausse page de connexion statique, celle qui affiche un formulaire, encaisse les identifiants et les revend pour plus tard, le code temporaire est efficace. Les six chiffres collectés à 14 h 02 ne valent plus rien à 14 h 03. L'attaquant doit être présent au moment de la frappe, ce qui change la nature de son travail et son coût.
Les problèmes que ça ajoute
La question qui revient, c'est de savoir si le code temporaire est meilleur que le SMS. Meilleur ne veut rien dire tant qu'on n'a pas dit sur quelle couche. Sur le transport, l'écart est net et il vient d'être décrit. Sur le geste de recopie, il n'y a aucun écart : six chiffres restent six chiffres qu'un humain tape quelque part.
Les six chiffres se recopient sur une page relais. C'est la limite structurelle du facteur, et elle n'a pas de contournement. Une page relais se place entre toi et le vrai service, transmet ton mot de passe, reçoit la demande de code, te la présente, prend tes six chiffres et les rejoue dans la seconde. Elle récupère le cookie de session et n'a plus jamais besoin de rien.
Pourquoi une page relais traverse-t-elle un code temporaire alors qu'elle bute sur une clé d'accès ? Parce qu'un code se recopie, et qu'une signature de clé ne se recopie pas.
Ce n'est pas une hypothèse de laboratoire. Kuba Gretzky publie Evilginx en avril 2017, en expliquant dans le même article comment l'outil traverse l'authentification à deux facteurs. En septembre 2022, la société Resecurity documente EvilProxy, la même mécanique vendue comme un service avec interface graphique, à partir de 150 dollars pour dix jours de campagne. La compétence requise est passée de « savoir configurer un proxy inverse » à « savoir remplir un formulaire ».
Le code se dicte au téléphone. Un faux conseiller qui appelle au bon moment obtient six chiffres aussi facilement qu'il obtiendrait un SMS. Le simulateur compte cette technique à 0,35 pour un attaquant ciblé, sans distinguer le type de code.
Le secret d'enrôlement se sauvegarde, donc se vole. Le QR code contient une chaîne qui reste valable tant que le facteur n'est pas réinitialisé. Une capture de ce QR code oubliée dans une galerie photo synchronisée, c'est le second facteur en clair, sans limite de durée.
Le téléphone perdu emporte les comptes. Le facteur qui ne dépend d'aucun réseau ne dépend que d'un objet. Dans les six scénarios de récupérabilité du modèle, « tu perds ton téléphone » porte le poids le plus lourd, 3 sur 10. Sans codes de secours et sans second appareil, le résultat est « compte perdu », soit zéro sur ce scénario.
La synchronisation cloud déplace le problème. Le 24 avril 2023, Google ajoute la synchronisation des codes de Google Authenticator avec le compte Google. Le problème de la perte du téléphone disparaît, et c'est un vrai gain pour beaucoup de gens. En échange, le compte Google devient un chemin vers tous les codes temporaires, et des chercheurs ont montré à la sortie de la fonction que le trafic de synchronisation n'était pas chiffré de bout en bout, Google pouvant donc lire les secrets. Le confort a un plafond, et le plafond porte un nom.
Les niveaux
Où vit le secret. Trois paliers, du plus courant au plus exigeant.
Dans une application dédiée sur le téléphone : le second facteur est séparé du mot de passe, le modèle compte deux facteurs distincts.
Dans le gestionnaire de mots de passe, à côté du mot de passe : c'est le piège du même coffre. Une seule ouverture donne les deux moitiés, et le modèle le signale comme défaut de structure. Le simulateur compte l'ouverture du coffre à [0,03, 0,15, 0,30] pour un gestionnaire dédié, contre [0,025, 0,06, 0,28] si le coffre exige lui-même un second facteur qui ne vit pas dedans. La deuxième colonne est celle qui bouge, parce que c'est l'attaquant ciblé qui sait ouvrir un coffre.
Sur une clé matérielle qui stocke les secrets TOTP : le secret ne quitte jamais la puce, et l'objet reste séparé du téléphone comme de l'ordinateur.
Les codes de secours. Ce n'est pas l'application qui décide de ta récupérabilité, c'est l'endroit où tu as posé ces codes. C'est le cran le plus négligé, et de loin.
Aucun code de secours : la perte du téléphone donne « compte perdu ». Les codes sur le même appareil que l'application : ils disparaissent avec lui. Les codes dans le coffre : bonne réponse pour la perte du téléphone, mauvaise si le coffre est déjà dans la chaîne d'attaque. Les codes sur papier chez toi : le compte survit à la perte du téléphone, pas à l'incendie ni au cambriolage, deux scénarios qui pèsent ensemble 2 sur 10. Les codes sur papier hors site, chez un proche ou dans un coffre bancaire : c'est le seul cran qui couvre les six scénarios. Le modèle le chiffre à 4 unités d'effort, soit environ quarante minutes une fois dans ta vie.