O QR de exportação do Google Authenticator é seguro de escanear?
Somente se você mesmo o gerou, no seu próprio celular antigo, com o seu novo celular apontado para a tela. Qualquer outra pessoa que fotografe aquele QR — por qualquer razão — obtém acesso permanente a todos os códigos 2FA de todas as contas no bundle.
O Google Authenticator e vários apps compatíveis (Aegis, Raivo OTP, 2FAS) permitem "exportar" suas contas 2FA armazenadas para movê-las para um novo dispositivo. A exportação assume a forma de um QR code com um URI que começa com otpauth-migration://. Dentro desse URI há um bundle de protocol-buffer único (esquema MigrationPayload do Google) contendo todas as contas de uma vez — emissor, nome da conta, semente secreta, algoritmo, contagem de dígitos, tipo (HOTP / TOTP) e contador.
O formato era originalmente não documentado, mas foi feito por engenharia reversa e agora é o formato de intercâmbio de fato para backups de 2FA. Apps autenticadores de terceiros reconhecem e importam o mesmo QR.
Um único QR pode conter dezenas de contas. O QR é visualmente indistinguível de um QR normal de configuração TOTP — não há nenhum marcador visual dizendo a um observador casual que ele carrega o bundle inteiro.
Por que um único QR de bundle é excepcionalmente perigoso
Um QR de configuração otpauth:// comum é perigoso de escanear se você não o solicitou, mas o raio de impacto é de uma conta. O raio de impacto do QR de migração é cada conta no seu autenticador. Se um atacante fotografar a tela exibindo este QR — por cima do seu ombro em um café, via câmera de segurança que você não percebeu, por uma janela de vidro transparente — ele vai embora com a capacidade de contornar o 2FA em todas as contas cobertas. Permanentemente. Até você rotacionar cada segredo manualmente, o que a maioria dos serviços não facilita.
Não há expiração nos segredos do bundle. Ao contrário de um token de sessão (que expira) ou de um QR de passkey (que é de uso único), as sementes num bundle de migração são válidas até você substituí-las serviço por serviço.
É por isso que o resultado do nosso scanner em todo QR otpauth-migration:// começa como provavelmente perigoso e permanece assim independentemente do contexto. O formato é adequado; o modelo de ameaça é a existência do formato.
O corpo base64, após decodificação, é um protocol-buffer MigrationPayload com estes campos de nível superior:
otp_parameters, repetido. Uma entrada por conta.
version, versão do esquema.
batch_size, total de fragmentos quando uma exportação é dividida em vários QRs.
batch_index, posição deste fragmento.
batch_id, ID único que vincula os fragmentos.
Cada entrada de otp_parameters tem:
secret, os bytes brutos da semente. Este é o material de chave real.
name, o rótulo da conta (ex.: alice@acme.com).
issuer, o nome do serviço (ex.: ACME, GitHub).
algorithm, SHA1 / SHA256 / SHA512 / MD5.
digits, 6 ou 8 dígitos por código.
type, TOTP (baseado em tempo) ou HOTP (baseado em contador).
counter, valor atual do contador para entradas HOTP.
O que nosso scanner exibe — e o que deliberadamente não exibe
✓ Exibido
Para cada entrada no bundle, o resultado mostra o emissor (ACME, GitHub, AWS), o nome da conta (alice@acme.com), o algoritmo (SHA1), a contagem de dígitos (6) e o tipo (TOTP). A divulgação do resultado lê "Contas neste bundle: ACME / alice@acme.com; GitHub / bob@github; AWS / root; …" para que um usuário em migração possa auditar a lista antes de importar.
Versão do esquema, índice do lote, tamanho do lote e ID do lote também são exibidos — útil quando uma exportação é fragmentada em vários QRs.
✗ Nunca decodificado
Os bytes brutos de secret nunca são decodificados na saída do resultado. Nosso analisador os lê apenas para verificar se cada entrada está bem formada (segredo presente e não vazio), depois descarta o valor antes de montar as descobertas.
Isso é verificado pelo conjunto de testes — alimentamos o analisador com payloads protobuf criados manualmente contendo strings canário (SECRET_SEED_1, SECRET_SEED_2) e afirmamos que essas strings nunca aparecem na saída serializada do resultado. Uma regressão lá falha no CI.
Quando (e como) usar
Caso de uso legítimo: você está trocando de celular. O celular ANTIGO exibe o QR de migração na tela por ~30 segundos. O app autenticador do celular NOVO aponta para a tela e importa. Ninguém mais está na sala. Você apaga a exportação do celular antigo depois de confirmar que tudo foi importado.
As superfícies de risco são:
Capturas de tela do QR. Uma captura salva em fotos sincronizadas na nuvem coloca o QR em todos os dispositivos sincronizados com aquela conta.
Compartilhar o QR por chat. Mesmo brevemente, qualquer pessoa com acesso ao chat (agora ou no futuro) pode extrair o bundle.
Postar o QR em um tópico de fórum de ajuda. Isso acontece com mais frequência do que se imagina — pessoas pedem ajuda e postam uma foto da exportação do autenticador por engano.
Cartazes/sinalização pública identificados erroneamente como QRs de configuração. O formato é visualmente indistinguível de um QR de configuração de conta única.
Se suspeitar que um QR de migração foi exposto
Trate como vazamento de credenciais em todas as contas do bundle. As etapas de recuperação, em ordem:
Acesse cada serviço afetado e rotacione o segredo 2FA. A maioria dos serviços permite isso em Conta → Segurança → Autenticação em dois fatores → Desativar e recadastrar.
Para serviços que não expõem rotação (raro, mas existe), remova e adicione novamente a conta.
Audite a atividade de login recente em cada conta afetada.
Delete o QR de exportação original de todos os dispositivos e bibliotecas de fotos sincronizadas na nuvem que possam tê-lo.
Um atacante com o bundle pode gerar códigos 2FA válidos por anos até você rotacionar. Não adie.
Envie a imagem do QR para o nosso scanner, cole o URI otpauth-migration:// ou use a câmera. O resultado mostra cada conta do bundle sem nunca decodificar os segredos.