MFA : pourquoi votre app Google Authenticator vous trahit

Un client me montre fièrement son téléphone. Google Authenticator, une vingtaine de comptes dedans, backup synchronisé. « Je suis blindé. » Trois semaines plus tôt, son compte Google avait servi de porte d’entrée : un faux email de partage de document, une page de connexion qui ressemblait à s’y méprendre à celle de Google, un code à six chiffres recopié sans réfléchir. L’attaquant n’a rien cassé. Le client lui a tendu le code, en temps réel, comme on tend ses clés au voiturier. Et son « blindage » était synchronisé sur le compte qui venait de tomber.

Le piège habituel

« J’ai activé le 2FA, je suis protégé. » C’est la phrase que j’entends le plus souvent en audit, et c’est la plus dangereuse du vocabulaire de la sécurité personnelle. Pas parce qu’elle est fausse au sens strict — le MFAAuthentification à plusieurs facteurs : combiner deux preuves d'identité indépendantes pour se connecter.Voir le lexique réduit réellement le risque par rapport à un simple mot de passe. Mais parce qu’elle range dans une unique case « protégé / pas protégé » des dispositifs qui n’ont rien à voir entre eux en termes de robustesse.

Le MFA n’est pas une catégorie unique, c’est un spectre. À un bout, le code par SMS, qui tombe au premier SIM swapAttaque où un fraudeur convainc votre opérateur de basculer votre numéro vers sa propre SIM.Voir le lexique venu. Au milieu, le TOTPCode à 6 chiffres généré toutes les 30 secondes par une app (Google Authenticator, Authy, etc.).Voir le lexique — ces codes à six chiffres qui changent toutes les trente secondes, le fameux Google Authenticator. À l’autre bout, le FIDO2Standard d'authentification forte par clé cryptographique matérielle, résistante au phishing.Voir le lexique, une clé matérielle ou une passkeyImplémentation grand public de FIDO2 : clé d'authentification stockée et synchronisée par Apple/Google/Microsoft.Voir le lexique qui refuse physiquement de s’authentifier sur le mauvais domaine. Entre le SMS et le FIDO2, il y a deux ordres de grandeur de différence sur la résistance au phishingAttaque par ingénierie sociale qui pousse la cible à donner ses identifiants ou exécuter du code.Voir le lexique. Mettre tout ça dans le même sac « 2FA », c’est dire « j’ai une serrure » sans préciser si c’est un loquet de salle de bains ou un cylindre certifié A2P.

La conséquence pratique est double, et les deux faces sont mauvaises. D’un côté, des gens qui se croient protégés et n’investissent pas dans la vraie protection, parce qu’ils pensent avoir déjà coché la case. De l’autre, l’illusion qui s’effondre au pire moment — pendant une attaque ciblée, en déplacement, sur le compte qui pilote toute leur vie numérique. Le TOTP n’est pas inutile. Mais le vendre comme une fin de partie, c’est la racine du problème.

Le modèle de menace réel : ce qui passe le TOTP

Le malentendu de fond, c’est de croire que le TOTP protège contre le phishing. Il ne protège pas. Il protège contre une chose précise — le vol de mot de passe sans interaction temps réel avec la victime — et c’est tout. Face à un attaquant qui vous parle au moment où vous vous connectez, le code à six chiffres est un facteur de plus à recopier, pas un mur.

Voici la mécanique concrète, celle que je vois dans les dossiers. L’attaquant ne construit pas une fausse page statique qui collecte votre mot de passe pour le rejouer plus tard. Il monte un reverse-proxyAttaque où un acteur s'interpose dans une communication entre deux parties qui se croient en direct.Voir le lexique entre vous et le vrai service — c’est une attaque dite adversary-in-the-middle (AiTM). Vous arrivez sur une page qui est, octet pour octet, la vraie page de connexion : ce n’est pas une copie, c’est la vraie page relayée en temps réel. Vous tapez votre identifiant, le proxy le transmet à Microsoft ou Google. Le vrai service demande le code TOTP. Vous le tapez. Le proxy le transmet aussi. Le service valide et renvoie un cookie de session authentifié — et c’est ce cookie que l’attaquant capture. Il a maintenant votre session active. Le code à six chiffres avait déjà été consommé ; il s’en moque, il a mieux : il est connecté en tant que vous, sans avoir à repasser par le MFA.

Cet outillage n’est pas réservé à des États-nations. Des frameworks open source comme EvilginxAttaque par ingénierie sociale qui pousse la cible à donner ses identifiants ou exécuter du code.Voir le lexique font exactement ça, clé en main, avec des « phishlets » préconfigurés pour Office 365, Google Workspace, Okta, les principaux fournisseurs. Le kit de phishing AiTM se loue à l’abonnement sur les forums criminels — du « phishing-as-a-service », avec hébergement, certificat TLSProtocole de chiffrement de transport, base de HTTPS et de la sécurité web moderne.Voir le lexique valide pour le domaine leurre et tableau de bord pour récolter les sessions volées. La barre technique pour bypasser votre TOTP est tombée au niveau d’un script-kiddie motivé. Microsoft a documenté des campagnes AiTM touchant des dizaines de milliers d’organisations. Ce n’est ni théorique, ni rare.

Le détail qui fait mal dans ce scénario, c’est que tous les réflexes qu’on vous a appris pour repérer le phishing échouent ici. Le cadenas TLS dans la barre d’adresse ? Présent — l’attaquant a un vrai certificat pour son domaine leurre. La page qui « a l’air vraie » ? Elle est vraie, relayée pixel pour pixel. Le code TOTP que vous tapez « parce que c’est bien le site » ? Il transite. Et même la notification push de validation, censée être « plus sûre » que le TOTP, ne résout rien : l’attaquant déclenche la connexion légitime au moment où vous validez, donc vous approuvez sa session en croyant approuver la vôtre. C’est le « MFA fatigue » dans sa version chirurgicale. Tout ce qui repose sur un humain qui recopie ou approuve un secret au bon moment est vulnérable, parce que l’humain ne peut pas distinguer le bon moment du mauvais quand le proxy est parfait.

Il faut aussi tuer une idée reçue tenace : « le TOTP est mathématiquement solide, donc l’app TOTP est solide ». Les deux propositions n’ont rien à voir. Oui, l’algorithme de la RFC 6238Code à 6 chiffres généré toutes les 30 secondes par une app (Google Authenticator, Authy, etc.).Voir le lexique est béton — un HMAC sur un compteur temporel, rien à redire. Mais la robustesse d’un facteur d’authentification ne se mesure pas à la force de son algorithme ; elle se mesure à ce qu’il faut pour le contourner en conditions réelles. Et en conditions réelles, on ne casse pas le HMAC : on intercepte le code en transit, ou on vole les graines au repos. L’algorithme parfait ne protège rien si le secret qu’il manipule fuit par les côtés.

Et c’est seulement le vecteur en ligne. Le TOTP a un second talon d’Achille, plus banal : le backup cloud. C’est le piège de mon client en ouverture. Quand vous synchronisez Google Authenticator avec votre compte Google, ou Authy avec votre compte Authy, vos graines TOTP — les secrets qui génèrent les codes — quittent votre téléphone pour vivre dans un cloud. À partir de là, votre « second facteur » n’est plus indépendant du premier : compromettre le compte cloud compromet l’ensemble de vos codes d’un seul mouvement. Vous avez transformé un facteur de possession en une extension de votre compte mail. Le jour où ce compte tombe — phishing, mot de passe réutilisé, fuite — l’attaquant récupère le coffre entier.

La bonne approche : hiérarchiser, puis basculer le critique vers FIDO2

La sortie n’est pas « supprimez le TOTP ». C’est « arrêtez de traiter tous vos comptes pareil, et mettez la vraie protection là où ça compte ». Posez d’abord la hiérarchie de robustesse, du pire au meilleur : SMS, puis TOTP cloud, puis TOTP local, puis FIDO2 matériel. Chaque cran monte d’une marche la résistance au phishing. Le SMS tombe au SIM swap. Le TOTP cloud tombe avec le compte cloud. Le TOTP local résiste au vol distant des graines mais reste « phishable » en temps réel via AiTM. Le FIDO2, lui, casse l’attaque AiTM par construction.

Pourquoi le FIDO2 est différent et pas seulement « mieux » : la cryptographie de WebAuthnAPI navigateur qui permet l'authentification FIDO2 sur les sites web.Voir le lexique lie l’authentification au domaine. La clé signe une réponse qui inclut l’origine exacte du site demandeur. Si vous êtes sur login-microsoft.attaquant.com au lieu de login.microsoftonline.com, la signature ne correspond pas, et la clé refuse — sans que vous ayez à repérer quoi que ce soit, sans jugement humain, sans « est-ce que cette URL est bizarre ? ». Le secret ne quitte jamais l’élément matériel : il n’y a pas de code à recopier, donc rien à intercepter dans le proxy. C’est ce que le CISA et le NISTInstitut américain qui publie les standards de référence en cybersécurité (CSF, SP 800-*).Voir le lexique appellent un MFA « résistant au phishing », par opposition à tout le reste. La distinction n’est pas marketing, elle est structurelle.

La bascule pragmatique tient en une règle : tout ce qui peut réinitialiser le reste passe en premier. Votre email principal est la racine — c’est par lui que transitent toutes les réinitialisations de mot de passe. Mettez-le sous FIDO2 avant tout le reste. Puis les comptes financiers, puis le gestionnaire de mots de passe, puis les consoles d’administration si vous en avez. Pour le reste — les centaines de comptes secondaires où FIDO2 n’est pas proposé ou pas justifié — gardez du TOTP, mais local, dans une app qui ne synchronise pas vos graines dans un cloud lié à votre identité. Aegis sur Android, Raivo ou Ente Auth sur iOS : graines chiffrées sur l’appareil, export manuel chiffré pour la sauvegarde, pas de backup automatique dans le compte que le TOTP est censé protéger. Et jamais, jamais le TOTP dans le même gestionnaire de mots de passe cloud que les mots de passe : sinon une seule compromission donne le facteur 1 et le facteur 2.

Concrètement, l’ordre des opérations compte autant que la cible, parce que la migration est le moment où l’on se verrouille soi-même par maladresse. La séquence que je fais appliquer : d’abord, j’enregistre les deux clés FIDO2 sur le compte cible pendant que l’ancienne méthode est encore active — on n’ajoute jamais un facteur fort en supprimant l’ancien dans le même geste. Ensuite je teste une déconnexion / reconnexion complète avec chacune des deux clés, séparément, pour vérifier qu’aucune n’a été enregistrée à moitié. Puis je récupère et stocke hors-ligne les codes de récupération que le service génère — sur papier, pas dans le gestionnaire qui dépend lui-même de ce compte. Et seulement alors je retire les méthodes faibles : SMS, OTP e-mail, et le cas échéant le TOTP devenu redondant. Sauter une de ces étapes, c’est soit se retrouver dehors, soit laisser une porte faible ouverte « provisoirement » — et le provisoire dure.

Le volet TOTP local mérite la même discipline, parce que son point faible n’est pas l’attaque mais la perte. Une app locale qui ne synchronise rien, c’est exactement ce qu’on veut côté sécurité — et exactement ce qui vous condamne le jour où le téléphone finit dans une cuvette si vous n’avez pas de sauvegarde. La parade tient en deux gestes : un export chiffré des graines (Aegis le fait en AES, protégé par une phrase de passe forte) stocké sur un support hors-ligne, et la conservation des codes de récupération de chaque service au moment de l’enrôlement. Vous n’avez pas besoin d’un cloud pour survivre à la perte d’un appareil ; vous avez besoin d’un export chiffré que vous contrôlez et d’une phrase de passe que vous seul connaissez.

Reste la question des passkeys, parce qu’on va vous les vendre comme la réponse universelle. Une passkeyImplémentation grand public de FIDO2 : clé d'authentification stockée et synchronisée par Apple/Google/Microsoft.Voir le lexique est du FIDO2 sous un nom grand public : même résistance au phishing par liaison au domaine, même cryptographie WebAuthnAPI navigateur qui permet l'authentification FIDO2 sur les sites web.Voir le lexique. La nuance est dans le stockage. Une passkey synchronisée dans iCloud ou dans votre compte Google hérite de la sécurité de ce compte — ce qui est très bien pour vos comptes ordinaires, et discutable pour la poignée de comptes dont la compromission est précisément le scénario que vous voulez exclure. Pour ces comptes-là, préférez une passkey non synchronisée stockée sur la clé matérielle elle-même, ou conservez deux clés FIDO2 physiques. Pour tout le reste, la passkey synchronisée est un excellent compromis robustesse / praticité, et largement supérieure au TOTP.

Dernier point qui n’est pas optionnel : deux clés FIDO2 minimum. Une que vous portez, une en sauvegarde dans un endroit sûr, les deux enregistrées sur chaque compte critique. Le mode d’échec classique du FIDO2 n’est pas l’attaque, c’est la perte de la clé unique qui vous verrouille dehors. Une clé seule, c’est un point unique de défaillance. Deux clés, c’est de la résilience.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• Synchroniser ses graines TOTP dans le cloud du compte qu’elles protègent. Google Authenticator backupé sur Drive, Authy verrouillé par SMS : le second facteur n’est plus indépendant du premier. Une compromission, tout tombe.
• Croire que le TOTP arrête le phishing. Il arrête le vol de mot de passe rejoué plus tard. Il ne fait rien contre un reverse-proxy AiTM qui relaie votre code en temps réel. La distinction est toute la différence.
• Mélanger mots de passe et TOTP dans le même gestionnaire cloud. Pratique, et c’est le problème : facteur 1 et facteur 2 dans le même panier, une seule fuite les donne tous les deux.
• Une seule clé FIDO2, sans secours. Le jour où vous la perdez, vous êtes verrouillé dehors — ou pire, vous rouvrez en urgence une méthode faible « le temps de » et vous ne la refermez jamais.
• Activer FIDO2 sur les comptes critiques mais laisser le SMS comme repli. Un attaquant ne s’attaque pas à votre clé : il prend l’option la plus faible encore disponible. Tant que le repli faible existe, le FIDO2 ne sert à rien.
• Oublier le parcours de récupération. Vous avez durci la connexion, pas la réinitialisation. Le helpdesk qui rebascule un MFA sur trois infos publiques annule tout le travail.

Checklist actionnable

• N1 Lister les comptes critiques (email principal, banque, gestionnaire de mots de passe, consoles admin)
• N1 Désactiver le backup/synchronisation cloud de l'app TOTP existante
• N1 Migrer le TOTP vers une app locale sans sync cloud (Aegis, Raivo, Ente Auth)
• N2 Acheter deux clés FIDO2 et enregistrer les deux sur l'email principal
• N2 Séparer physiquement les mots de passe et les graines TOTP (supports distincts)
• N2 Basculer banque et gestionnaire de mots de passe vers FIDO2 quand disponible
• N3 Désactiver le SMS et l'OTP e-mail comme repli sur les comptes passés en FIDO2
• N3 Provisionner une clé FIDO2 de secours stockée hors domicile principal
• N3 Auditer et durcir les parcours de récupération de compte (vérification d'identité forte)

Pour aller plus loin

La distinction entre MFA « phishable » et MFA résistant au phishing n’est pas une opinion : elle est posée noir sur blanc par le NIST (SP 800-63B) et détaillée par le CISA dans son guide d’implémentation du MFA résistant au phishing — les deux références à lire si vous devez argumenter une migration en interne. Pour comprendre ce que FIDO2 garantit cryptographiquement, allez voir les spécifications de la FIDO Alliance ; pour le fonctionnement exact du TOTP et ses limites, la RFC 6238 est courte et lisible. Et si vous doutez encore que l’attaque AiTM soit à la portée d’un attaquant ordinaire, la documentation publique d’Evilginx suffit à se faire une idée du niveau d’effort réel — c’est-à-dire faible.