Um app de autenticação nunca recebe o código que mostra para você. Quando você liga a verificação em duas etapas, o site entrega um segredo — normalmente 20 bytes aleatórios, escondidos dentro daquele QR code — e seu app fica com a própria cópia. Daí em diante os dois lados fazem a mesma aritmética: pegam a hora Unix atual, dividem por 30 e descartam o resto, passam esse número por HMAC usando o segredo compartilhado como chave e depois espremem a saída até sobrarem seis dígitos. Seu telefone mostra a resposta dele, o servidor calcula a própria, e as duas batem porque as entradas batiam. Nada é trocado, e é por isso que o app continua funcionando dentro de um avião.
O que existe de fato dentro do QR code
Texto, e não muito. O QR code é um jeito compacto de digitar uma única URL:
otpauth://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Example
A única parte que importa é secret. O resto é rotulagem: o issuer e o nome da conta existem para que seu app consiga mostrar "Example" ao lado do código em vez de uma fileira de dígitos anônimos. O formato permite mais três parâmetros, algorithm, digits e period, e vários apps bastante usados ignoram os três, presumindo SHA-1, seis dígitos e trinta segundos, diga o que disser o link.
O segredo é escrito em base32: as letras de A a Z e os dígitos de 2 a 7. Não existe 0, nem 1, nem 8, justamente porque são os caracteres que as pessoas leem errado como O, I e B ao copiar uma chave à mão. Ele também não diferencia maiúsculas de minúsculas, coisa que base64 faz. O preço é o tamanho: 20 bytes precisam de 32 caracteres em base32 onde base64 teria usado 27.
Os quatro passos que transformam o relógio em seis dígitos
- Contar os intervalos. Pegue o timestamp Unix, os segundos decorridos desde 1 de janeiro de 1970, divida por 30 e jogue fora a fração. Em 2026 isso é um número um pouco abaixo de 60 milhões, subindo duas vezes por minuto em todo relógio ajustado corretamente.
- Aplicar um hash com o segredo. O contador é escrito como oito bytes e passa por HMAC-SHA-1, com o segredo como chave. HMAC é um hash com chave: a mesma entrada sob outra chave produz uma saída sem relação nenhuma, e a saída não conta nada sobre a chave. Se esse passo deixa coisa demais sem explicação, o que é um hash e o que não é cobre o terreno que sustenta esse passo.
- Truncar, de um jeito esquisito. O HMAC-SHA-1 dá 20 bytes, muito mais do que dá para digitar. Os últimos quatro bits desse resultado são lidos como um número de 0 a 15, e esse número é usado como deslocamento de volta para dentro do próprio resultado: quatro bytes são retirados dali, e o bit mais alto é descartado. Descartar o bit não tem nada a ver com segurança. Existe para que as implementações que tratam o valor como com sinal e as que tratam como sem sinal cheguem ao mesmo número.
- Ficar com o resto. O que sobra é um número de 31 bits. Módulo um milhão, ele vira os seis dígitos que você lê. Mais ou menos um código em cada dez cai abaixo de 100000, e é por isso que os apps completam com zeros à esquerda.
Nada disso é novo. O original baseado em contador, o HOTP, é a RFC 4226 de dezembro de 2005, escrita para rodar num token de chaveiro com quase nenhum processador. O TOTP é a RFC 6238 de maio de 2011: a mesma construção com o relógio no lugar do contador. O passo de truncamento parece estranho porque é um fóssil daquele hardware.
Por que 30 segundos
É um meio-termo, e bem arbitrário. Um intervalo mais curto faz um código roubado valer menos, mas também significa que quem digita devagar no teclado do telefone vê o número mudar no meio do caminho. Trinta segundos dão para ler um código numa tela e digitá-lo em outra, e são pouco o bastante para que um código capturado num screenshot normalmente já esteja vencido quando alguém o encontrar.
Só existe um milhão de códigos possíveis de seis dígitos, então não é o tamanho que torna o TOTP difícil de vencer. O que impede o chute é o servidor contar as tentativas que falham, não a aritmética. Um formulário de login que deixa alguém testar códigos a tarde inteira está quebrado, não importa como os números sejam produzidos.
Por que um código digitado com atraso ainda funciona
Porque o servidor normalmente verifica mais de um intervalo. Relógios se desviam, e sem isso um telefone três segundos atrasado falharia em um login a cada dois. A maioria das implementações aceita o intervalo anterior e o seguinte junto com o atual, uma janela de cerca de 90 segundos. Algumas são mais rígidas, e é por isso que o mesmo código atrasado passa tranquilo em um site e é recusado em outro.
Por que seus códigos param de funcionar de repente
São poucas as causas.
- O relógio do aparelho se desviou. A causa mais comum, de longe. Um telefone com dois minutos de diferença produz códigos errados em todo lugar ao mesmo tempo, o que se parece exatamente com um segredo corrompido.
- O algoritmo não bate. Se o link de configuração pedia SHA-256 e o app usou SHA-1 sem avisar, cada código é um código TOTP válido para os parâmetros errados.
- O segredo foi copiado errado. Um O maiúsculo digitado onde base32 não tem zero, ou um l minúsculo no lugar de um 1. Um único caractere errado muda todos os códigos.
- É a entrada errada. Duas contas do mesmo serviço lado a lado numa lista comprida.
Separar uma coisa da outra fica mais rápido com uma segunda opinião. Se você ainda tem a seed original, cole num gerador de códigos TOTP em outro computador e compare os dois códigos no mesmo momento. Códigos diferentes significam que um dos dois relógios está errado. O mesmo código nos dois, e ainda assim recusado pelo site, aponta para o algoritmo, para a quantidade de dígitos ou para a entrada errada — não para a seed.
O que o TOTP resolve e o que não resolve
Ele acaba com o credential stuffing. Uma senha vazada no vazamento de outra pessoa, ou reutilizada em uma dúzia de sites, deixa de ser suficiente sozinha. Para esse trabalho o TOTP é excelente e quase de graça.
Ele não impede o phishing. Um código digitado numa página falsa convincente vale trinta segundos para quem estiver repassando para o site de verdade, e os kits de phishing fazem exatamente isso, ao vivo, enquanto a vítima espera a página carregar. Passkeys e chaves de segurança de hardware fecham esse buraco porque o login fica preso à origem do site; um número de seis dígitos que você consegue ler em voz alta não tem como ficar preso a nada.
Ele também não conserta uma senha ruim. O servidor precisa guardar sua seed num formato que consiga ler de volta, já que precisa recalcular seus códigos, então um vazamento desse banco de dados entrega a um atacante um gerador de códigos permanente, não um hash de senha que ainda precise ser quebrado. A senha passa a ser a única coisa de pé. Se você vinha tratando o segundo fator como permissão para manter um primeiro fraco, quanto tempo levaria para quebrar sua senha são cinco minutos bem gastos.
A seed é o que você precisa guardar
Perder o telefone é menos catastrófico do que as pessoas imaginam, desde que a seed tenha sobrevivido em algum lugar. No TOTP não existe passo de pareamento nem identidade de aparelho em lugar nenhum: dois aparelhos com o mesmo segredo mostram o mesmo código, porque quem tem o segredo é você no que diz respeito ao protocolo. Isso também é o aviso: uma foto do QR code de configuração na sua galeria é um segundo fator funcionando para qualquer um que entre nas suas fotos.
Guarde os códigos de recuperação que o site oferece na configuração, e deixe-os em algum lugar que não seja o telefone. São o único caminho de volta depois que a seed some, e os serviços lidam mal com a ausência deles, normalmente pedindo uma foto do seu passaporte.
Um aviso honesto sobre fazer qualquer uma dessas coisas numa aba do navegador. Uma página capaz de calcular seus códigos está segurando sua seed enquanto estiver aberta, e colar uma seed em uso em qualquer lugar é uma decisão, não um reflexo. O gerador daqui não escreve nada no armazenamento, não cria nenhum cookie, não coloca nada na URL e esquece o segredo quando a página recarrega — mas ele existe para testar uma implementação, confirmar que um backup ainda funciona, ou entrar uma vez quando o telefone está em outro lugar. Não é um app de autenticação, e também não consegue ler um QR code: não tem câmera nem decodificador dentro dele, então você precisa da seed em texto que os sites escondem atrás do link "não consegue escanear o código?".
Quando você precisa conferir uma seed agora mesmo — depois de uma migração, ou quando o telefone com o app não está na sala — o gerador de códigos TOTP transforma um segredo em base32 ou um link otpauth completo no código atual e nos segundos que restam dele, sem o segredo sair da página. Trate isso como um diagnóstico, não como o lugar onde guardar suas contas. E como um segundo fator só compra tempo para o primeiro, os argumentos a favor de uma frase-senha em vez de uma senha são a outra metade desse problema, ainda mais se o site que guarda sua seed for justamente o que for invadido.
Perguntas frequentes
Como um app de autenticação gera códigos sem internet?
Ele não precisa de conexão porque nada é enviado. O app e o servidor têm o mesmo segredo e cada um calcula um código a partir da hora atual, então os números batem sem nunca terem sido trocados. A única entrada compartilhada é o relógio, e é por isso que um telefone offline continua funcionando mas um telefone com a hora errada não.
Por que meu código do autenticador aparece como inválido?
Quase sempre é um relógio que se desviou mais de um minuto, já que a hora é metade do cálculo. As outras causas são um segredo copiado com um caractere errado, um app usando SHA-1 onde o site esperava SHA-256, ou simplesmente a entrada errada numa lista comprida. Acerte a hora do telefone primeiro, antes de supor que a configuração está quebrada.
Dois telefones podem mostrar o mesmo código 2FA?
Podem. O TOTP não tem noção de aparelho, então qualquer quantidade de apps com o mesmo segredo produz códigos idênticos no mesmo momento. É assim que as pessoas mantêm um aparelho reserva, e é também por isso que uma foto do QR code de configuração é tão sensível quanto a própria senha.
Um app de autenticação é mais seguro do que códigos por SMS?
É, por um motivo específico: o código nunca viaja, então não há nada para interceptar nem número de telefone para sequestrar por SIM swap. Os dois são igualmente vulneráveis a uma página de phishing que repassa seu código para o site real em tempo real. Só passkeys ou uma chave de segurança de hardware fecham essa brecha, porque prendem o login ao endereço do site.
O que acontece se eu perder o telefone com meu app de autenticação?
Você perde o acesso a toda conta cujo segredo existia só naquele telefone. Os códigos de recuperação salvos na configuração são o caminho normal de volta, e um backup da própria seed também funciona. Sem um nem outro, sobra a recuperação manual de conta que o serviço oferecer, o que normalmente significa documento de identidade e espera.
Última atualização 19 de setembro de 2026