Is de Google Authenticator export-QR veilig om te scannen?
Alleen als u hem zelf hebt gegenereerd, op uw eigen oude telefoon, met uw eigen nieuwe telefoon gericht op het scherm. Iedereen die die QR fotografeert, om welke reden dan ook, krijgt permanente toegang tot elke 2FA-code voor elk account in de bundel.
Google Authenticator en verschillende compatibele apps (Aegis, Raivo OTP, 2FAS) laten u uw opgeslagen 2FA-accounts "exporteren" zodat u ze naar een nieuw apparaat kunt verplaatsen. De export bestaat uit een QR-code met een URI die begint met otpauth-migration://. Binnen die URI zit een enkele protocol-buffer bundel (Google's MigrationPayload-schema) die alle accounts tegelijk bevat — uitgever, accountnaam, geheim seed, algoritme, cijferaantal, type (HOTP / TOTP) en teller.
Het formaat was oorspronkelijk ongedocumenteerd, maar is door reverse-engineering ontleed en is nu het de-facto uitwisselingsformaat voor 2FA-back-ups. Authenticator-apps van derden herkennen en importeren dezelfde QR.
Eén QR kan tientallen accounts bevatten. De QR is visueel niet te onderscheiden van een normale TOTP-installatie-QR — er is geen visuele markering die een vluchtige waarnemer vertelt dat hij de hele bundel bevat.
Waarom een enkele bundel-QR uniek gevaarlijk is
Een gewone otpauth:// installatie-QR is gevaarlijk om te scannen als u hem niet zelf hebt aangevraagd, maar de blast radius is één account. De blast radius van de migratie-QR is elk account in uw authenticator. Als een aanvaller een foto maakt van het scherm dat deze QR toont — over uw schouder in een koffieshop, via een bewakingscamera die u niet opmerkte, door een helder glazen raam — loopt hij weg met de mogelijkheid om 2FA te omzeilen op elk account dat erin zat. Permanent. Totdat u elk geheim handmatig roteert, wat de meeste diensten niet eenvoudig maken.
Er is geen vervaldatum op de geheimen in de bundel. In tegenstelling tot een sessietoken (dat verloopt), in tegenstelling tot een passkey-QR (die eenmalig is), zijn de seeds in een migratiebundel geldig totdat u ze service voor service vervangt.
Dat is waarom het vonnis van onze scanner voor elke otpauth-migration:// QR begint bij waarschijnlijk_gevaarlijk en daar blijft, ongeacht de context. Het formaat is prima; het dreigingsmodel is het bestaan van het formaat.
De base64-inhoud, eenmaal gedecodeerd, is een MigrationPayload protocol-buffer met deze velden op het hoogste niveau:
otp_parameters, herhaald. Eén item per account.
version, schema-versie.
batch_size, totaal aantal delen wanneer een export wordt verdeeld over meerdere QR's.
batch_index, de positie van dit deel.
batch_id, uniek ID dat de delen aan elkaar koppelt.
Elk otp_parameters-item heeft:
secret, de ruwe seed-bytes. Dit is het eigenlijke sleutelmateriaal.
name, het accountlabel (bijv. alice@acme.com).
issuer, de servicenaam (bijv. ACME, GitHub).
algorithm, SHA1 / SHA256 / SHA512 / MD5.
digits, 6 of 8 cijfers per code.
type, TOTP (tijdgebaseerd) of HOTP (tellergebaseerd).
counter, huidige tellerwaarde voor HOTP-items.
Wat onze scanner toont, en wat hij bewust niet toont
✓ Getoond
Voor elk item in de bundel toont het vonnis de uitgever (ACME, GitHub, AWS), de accountnaam (alice@acme.com), het algoritme (SHA1), het cijferaantal (6) en het type (TOTP). De vonnisonthulling luidt "Grants in deze bundel: ACME / alice@acme.com; GitHub / bob@github; AWS / root; …" zodat een gebruiker die MID-migratie is de lijst kan controleren voor het importeren.
Schema-versie, batch-index, batch-grootte en batch-ID worden ook getoond — nuttig wanneer een export wordt gesplitst over meerdere QR's.
✗ Nooit gedecodeerd
De ruwe secret-bytes worden nooit gedecodeerd in de vonnisuitvoer. Onze analyser leest ze alleen om te verifiëren dat elk item goed gevormd is (geheim aanwezig + niet leeg), en verwijdert de waarde daarna voordat de bevindingen worden gebouwd.
Dit wordt bevestigd door de testuite — we voeren de analyser hand-gemaakte protobuf-payloads in met canary-strings (SECRET_SEED_1, SECRET_SEED_2) en stellen dat die strings nooit voorkomen in de geserialiseerde vonnisuitvoer. Een regressie daar mislukt CI.
Wanneer (en hoe) u er één gebruikt
Legitiem gebruiksgeval: u stapt over van de ene telefoon naar de andere. De OUDE telefoon toont de migratie-QR op zijn scherm gedurende ~30 seconden. De authenticator-app op de NIEUWE telefoon richt op het scherm en importeert. Niemand anders is in de kamer. U verwijdert de export van de oude telefoon nadat u hebt bevestigd dat alles is geïmporteerd.
De gevaarsoppervlakken zijn:
Schermafbeeldingen van de QR. Een schermafbeelding opgeslagen in gesynchroniseerde cloudfoto's plaatst de QR op elk apparaat dat met dat account is gesynchroniseerd.
De QR delen via chat. Zelfs kort: iedereen met toegang tot de chat (nu of later) kan de bundel extraheren.
De QR plaatsen in een helpforumthread. Dit gebeurt vaker dan u denkt; mensen vragen om hulp en plaatsen per ongeluk een foto van hun authenticator-export.
Openbare posters / bewegwijzering die verkeerdelijk worden geïdentificeerd als installatie-QR's. Het formaat is visueel niet te onderscheiden van een enkele-account installatie-QR.
Als u vermoedt dat een migratie-QR is blootgesteld
Behandel dit als een referentielek voor elk account in de bundel. De herstelstappen, op volgorde:
Log in op elke getroffen service en roteer het 2FA-geheim. De meeste diensten laten u dit doen onder Account → Beveiliging → Twee-factor authenticatie → Uitschakelen en opnieuw inschrijven.
Voor diensten die rotatie niet bieden (zeldzaam maar bestaat): verwijder het account en voeg het opnieuw toe.
Controleer recente aanmeldingsactiviteit op elk getroffen account.
Verwijder de originele export-QR van elk apparaat en gesynchroniseerde fotobibliotheek die hem mogelijk bevat.
Een aanvaller met de bundel kan jarenlang geldige 2FA-codes produceren totdat u roteert. Stel dit niet uit.
Sleep de QR-afbeelding in onze scanner, plak de otpauth-migration://-URI, of gebruik de camera. Het vonnis toont elk account in de bundel zonder de geheimen ooit te decoderen.