Gerador de Código TOTP (2FA) Online

Gerador e validador de código TOTP

Informe um segredo em Base32 (ou gere um aleatório) e veja o código TOTP do momento, com contagem regressiva, o código anterior e o próximo. A ferramenta também monta a URI otpauth:// com QR Code para ler no app autenticador, lê uma URI pronta e confere se um código digitado é válido. Tudo é calculado no seu navegador: o segredo não é enviado a nenhum servidor nem fica salvo.

Para que serve (e para que não serve)

Esta página é uma ferramenta de desenvolvimento e teste: conferir se o backend que você está escrevendo gera o mesmo código que um app autenticador, depurar um cadastro de 2FA que “nunca aceita o código”, montar a URI do QR Code ou descobrir quais parâmetros vêm dentro de uma URI otpauth://.

Ela não substitui o app autenticador das suas contas. O segredo TOTP é o segundo fator: quem o tem gera os mesmos códigos que você, para sempre. Colar o segredo de uma conta real num site — qualquer site, mesmo um que não envia nada, como este — ou guardá-lo junto da senha transforma dois fatores em um. Use aqui apenas segredos de teste.

O que é TOTP e 2FA

2FA (autenticação em dois fatores) é pedir, além da senha, uma segunda prova de identidade. TOTP (Time-based One-Time Password, senha de uso único baseada em tempo) é o método por trás dos apps autenticadores como Google Authenticator, Microsoft Authenticator, Authy e Aegis: aquele código de 6 dígitos que muda a cada 30 segundos.

O TOTP é definido na RFC 6238 (2011) e é uma variação do HOTP, da RFC 4226 (2005). No HOTP o código depende de um contador que avança a cada uso; no TOTP o contador é o próprio relógio.

Como o código é calculado

No cadastro, o servidor gera um segredo aleatório e o mostra ao usuário, quase sempre como QR Code. A partir daí os dois lados fazem a mesma conta, sem trocar mais nada pela rede:

1. Contador: T = floor(segundos desde 01/01/1970 UTC ÷ 30). O valor muda a cada 30 segundos e independe de fuso horário.
2. HMAC: calcula-se HMAC-SHA-1(segredo, T), com T em 8 bytes, big-endian.
3. Truncamento dinâmico: os 4 bits finais do HMAC indicam uma posição; os 4 bytes a partir dela, com o primeiro bit zerado, formam um número de 31 bits.
4. Dígitos: o código é esse número módulo 10⁶, com zeros à esquerda (10⁸ para 8 dígitos).

Exemplo conferido com os vetores de teste das RFCs: o segredo ASCII 12345678901234567890 é, em Base32, GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ. No instante Unix 59, T = floor(59 ÷ 30) = 1, e o código com SHA-1 é 287082 (6 dígitos) ou 94287082 (8 dígitos). Cole esse segredo na ferramenta para ver que os parâmetros funcionam — o código exibido será o da hora atual.

O relógio precisa estar certo

Como o contador vem da hora, um relógio adiantado ou atrasado gera códigos de outro período. Por isso os servidores costumam aceitar também o código vizinho: a RFC 6238 recomenda tolerar no máximo um período de atraso de rede. O validador desta página deixa escolher a tolerância (só o atual, ±1 ou ±2). Um site estático não tem como saber se o relógio do seu aparelho está errado; se o código não bate, confira se a data e a hora estão em ajuste automático.

Segredo em Base32

O segredo é uma sequência de bytes, mostrada em Base32 (RFC 4648): letras de A a Z e dígitos de 2 a 7. Não existem 0, 1, 8 nem 9, o que evita confusão com O e I. A ferramenta aceita minúsculas, espaços e hifens, e o = de preenchimento é opcional.

A RFC 4226 exige segredo de pelo menos 128 bits e recomenda 160 bits — 20 bytes, que em Base32 dão 32 caracteres. É o tamanho que o botão “Gerar segredo” produz, com o gerador criptográfico do navegador (crypto.getRandomValues).

A URI otpauth:// e o QR Code

O QR Code do cadastro de 2FA contém só um texto no formato Key URI, criado para o Google Authenticator e adotado pelos demais apps:

otpauth://totp/Minha%20Loja:ana%40exemplo.com.br?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Minha%20Loja&algorithm=SHA1&digits=6&period=30

• Rótulo (Emissor:conta): o que aparece no app. Emissor e conta vão com percent-encoding, e nenhum dos dois pode conter :.
• secret: o segredo em Base32, sem =. É o único parâmetro obrigatório.
• issuer: o nome do serviço; recomenda-se repetir o mesmo emissor do rótulo.
• algorithm (SHA1, SHA256 ou SHA512), digits (6 ou 8) e period (segundos): opcionais; os padrões são SHA1, 6 e 30.

Atenção ao sair do padrão: a própria documentação do formato avisa que versões do Google Authenticator ignoram algorithm, digits e period e usam sempre SHA-1, 6 dígitos e 30 segundos. Se você precisa que o 2FA funcione em qualquer app, fique no padrão. O SHA-1 aqui não é um problema: as colisões conhecidas do SHA-1 não afetam o uso em HMAC.

TOTP, SMS e passkeys

• Código por SMS: depende da operadora e do número de telefone. Pode ser desviado por troca de chip (SIM swap) ou interceptado, e não funciona sem sinal. O TOTP é calculado no aparelho, sem rede e sem operadora.
• TOTP: bem mais seguro que SMS, mas o código continua sendo algo que a pessoa digita — e que uma página falsa pode pedir e repassar ao site verdadeiro em segundos. TOTP não protege contra phishing em tempo real.
• Passkeys (FIDO2/WebAuthn): usam um par de chaves; a chave privada não sai do aparelho e a assinatura fica vinculada ao domínio do site, então uma página falsa não consegue aproveitá-la. São resistentes a phishing e não há segredo compartilhado que possa vazar do servidor.

Como implementar e testar o 2FA

1. Gere um segredo aleatório de 160 bits por usuário e guarde-o cifrado no servidor (ele precisa ser recuperável; não dá para guardar só o hash, como numa senha).
2. Mostre o QR Code da URI otpauth:// e o segredo em texto, para quem não consegue ler o QR.
3. Só ative o 2FA depois que o usuário digitar um código válido — é a prova de que o app foi configurado.
4. Na validação, aceite o período atual ±1, recuse um código já usado (a RFC 6238 determina que o mesmo código não seja aceito duas vezes) e limite as tentativas: 6 dígitos são 1 milhão de possibilidades.
5. Ofereça códigos de recuperação e mantenha o servidor sincronizado por NTP.

Para testar, gere um segredo aqui, leia o QR Code no app autenticador e compare os três: o código do app, o desta página e o do seu backend. Se só o seu backend diverge, as causas comuns são usar o texto Base32 como chave em vez dos bytes decodificados, montar o contador com menos de 8 bytes, usar milissegundos no lugar de segundos ou perder os zeros à esquerda do código.

Perguntas frequentes

É seguro usar este gerador com o segredo das minhas contas?

Não faça isso. A página calcula tudo localmente, não envia e não salva o segredo, mas o princípio do segundo fator é que o segredo exista em um só lugar, separado da senha. Para contas reais, use um app autenticador ou uma chave de segurança.

Por que o código daqui é diferente do código do meu app?

Em ordem de probabilidade: relógio errado em um dos aparelhos; segredo digitado com erro; algoritmo, dígitos ou período diferentes dos que o app está usando; ou o app ignorou os parâmetros da URI e usou SHA-1, 6 dígitos e 30 segundos.

Qual a diferença entre TOTP e HOTP?

Os dois usam a mesma conta. No HOTP o contador é um número que avança a cada código gerado, e servidor e aparelho precisam se manter em sincronia. No TOTP o contador é o tempo dividido pelo período, então o código expira sozinho.

Posso usar SHA-256 ou SHA-512?

A RFC 6238 permite, e esta ferramenta calcula os três. O limite é a compatibilidade: nem todo app autenticador respeita o parâmetro algorithm. Teste com os apps que seus usuários usam antes de sair do SHA-1.

O código tem 6 dígitos; isso não é pouco?

Seria, se desse para tentar à vontade. A segurança vem do conjunto: o código vale por cerca de 30 segundos, o servidor limita as tentativas e ainda exige a senha.

O segredo fica salvo no navegador?

Não. Ele existe apenas na memória da página enquanto ela está aberta; ao recarregar, um novo segredo de teste é gerado.

Veja também

• Codificador e decodificador Base32
• Gerador de HMAC
• Gerador de QR Code
• Conversor de timestamp Unix
• Gerador de senha
• Decodificador de JWT