Le QR d’export Google Authenticator est-il sûr à scanner ?
Seulement si vous l’avez généré vous-même, sur votre propre ancien téléphone, avec votre propre nouveau téléphone pointé vers l’écran. Tout autre contexte est une fuite de credentials 2FA.
Google Authenticator et plusieurs applications compatibles (Aegis, Raivo OTP, 2FAS) permettent d’« exporter » vos codes 2FA stockés en un ou plusieurs QR codes. Le format est otpauth-migration://offline?data=<base64>.
Le format était initialement non documenté, mais il a été inversé par rétro-ingénierie et est maintenant le standard de fait pour la migration inter-applications des secrets TOTP.
Un seul QR peut contenir des dizaines de comptes. Il est visuellement indiscernable d’un QR de configuration TOTP ordinaire.
Pourquoi un seul QR de lot est uniquement dangereux
Un QR de configuration otpauth:// ordinaire est dangereux à scanner si vous ne l'avez pas demandé, mais le rayon de l'explosion se limite à un seul compte. Le rayon d'explosion du QR de migration couvre chaque compte de votre authentificateur. Si un attaquant photographie l'écran affichant ce QR, par-dessus votre épaule dans un café, via une caméra de surveillance que vous n'avez pas remarquée, à travers une vitre transparente, il repart avec la capacité de contourner le 2FA sur chaque compte concerné. De façon permanente. Jusqu'à ce que vous fassiez pivoter chaque secret manuellement, ce que la plupart des services ne facilitent pas.
Les secrets du lot n’ont pas de date d’expiration. Contrairement à un jeton de session (qui expire), contrairement à un mot de passe (que vous pouvez changer sans affecter les autres comptes), les secrets TOTP bruts restent valides jusqu’à ce que vous les fassiez tourner un par un.
C’est pourquoi le verdict de notre scanner sur chaque QR otpauth-migration:// commence à limite, même pour les QR générés par vous-même : le risque est structurel, pas contextuel.
Ce qui se trouve réellement à l’intérieur (anatomie)
Le corps base64, une fois décodé, est un protocol-buffer MigrationPayload avec ces champs de premier niveau :
otp_parameters, répété. Une entrée par compte.
version, version du schéma.
batch_size, nombre total de morceaux quand un export est réparti sur plusieurs QR.
batch_index, position de ce morceau dans le lot.
batch_id, identifiant unique liant les morceaux entre eux.
Chaque entrée otp_parameters contient :
secret, les octets bruts de la graine. Il s’agit du matériau de clé réel.
name, le libellé du compte (ex. : alice@acme.com).
issuer, le nom du service (ex. : ACME, GitHub).
algorithm, SHA1 / SHA256 / SHA512 / MD5.
digits, 6 ou 8 chiffres par code.
type, TOTP (basé sur le temps) ou HOTP (basé sur un compteur).
counter, valeur actuelle du compteur pour les entrées HOTP.
Ce que notre scanner affiche, et ce qu’il ne décode délibérément pas
✓ Affiché
Pour chaque entrée du lot, le verdict affiche l’émetteur (ACME, GitHub, AWS), le nom du compte (alice@acme.com), le type (TOTP/HOTP), le nombre de chiffres et l’algorithme.
La version du schéma, l’index de lot, la taille du lot et l’identifiant du lot sont également affichés, utiles quand un export est fragmenté sur plusieurs QR.
✗ Jamais décodé
Les octets bruts du secret ne sont jamais décodés dans la sortie du verdict. Notre analyseur les lit pour confirmer leur présence, en vérifie la longueur, et c’est tout.
Cela est vérifié par la suite de tests : nous alimentons l'analyseur avec des charges utiles protobuf forgées manuellement contenant des chaînes canaris (SECRET_SEED_1, SECRET_SEED_2) et nous nous assurons que ces chaînes n'apparaissent jamais dans la sortie du verdict sérialisé. Une régression à ce niveau fait échouer l'intégration continue.
Quand (et comment) en utiliser un
Cas d’usage légitime : vous changez de téléphone. L’ANCIEN téléphone affiche le QR de migration, votre NOUVEAU téléphone le scanne. Cela s’effectue en privé, en une fois, sans intermédiaire.
Les surfaces dangereuses sont :
Captures d’écran du QR. Une capture d’écran enregistrée dans des photos synchronisées dans le cloud place le QR sur chaque appareil synchronisé.
Partager le QR par chat. Même brièvement, quiconque a accès au chat (maintenant ou plus tard) possède tous les secrets 2FA.
Publier le QR dans un fil d’aide sur un forum. Cela arrive plus souvent qu’on ne le pense ; les gens cherchent de l’aide pour la migration et joignent une capture d’écran.
Affiches / enseignes publiques mal identifiées comme QR de configuration. Le format est visuellement indiscernable d’un QR de configuration TOTP habituel.
Si vous soupconçonnez qu’un QR de migration a été exposé
Traitez cela comme une fuite de credentials sur chaque compte du lot. Les étapes de récupération, dans l’ordre :
Connectez-vous à chaque service affecté et faites pivoter le secret 2FA. La plupart des services vous permettent de le faire via Compte → Sécurité → Authentification à deux facteurs → Désactiver puis réenrôler.
Pour les services qui n’exposent pas la rotation (rare mais possible), supprimez et rajoutez le compte.
Consultez l’activité de connexion récente sur chaque compte affecté.
Supprimez le QR d’export original de chaque appareil et de toute bibliothèque photo synchronisée dans le cloud qui pourrait le contenir.
Un attaquant avec le lot peut produire des codes 2FA valides pendant des années jusqu’à ce que vous fassiez tourner les secrets. Ne reportez pas.
Déposez l’image QR dans notre scanner, collez l’URI otpauth-migration:// ou utilisez la caméra. Le verdict liste chaque compte du lot sans exposer les secrets bruts.