Gerador de TOTP Secret

O que é um secret TOTP

Um secret TOTP é a chave simétrica compartilhada que um aplicativo autenticador (Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator) e o seu servidor mantêm independentemente para calcular o mesmo código de seis dígitos a cada 30 segundos. O algoritmo está descrito na RFC 6238 (2011), que estende a antiga RFC 4226 (HOTP) trocando o contador por um fator móvel baseado em tempo. Cada código é o resultado de HMAC-SHA1(secret, floor(unix_time / 30)) truncado para seis dígitos — não há round-trip de rede no momento em que o usuário digita.

A RFC recomenda um secret de 160 bits (20 bytes), mesmo tamanho da saída do SHA-1; muitos serviços aceitam entre 80 e 160 bits, mas descer abaixo de 128 bits enfraquece o esquema contra busca exaustiva no espaço de chaves. Os bytes são codificados em Base32 (RFC 4648, sem padding, alfabeto A-Z2-7) justamente porque exclui os caracteres 0, 1, 8 e 9 — visualmente ambíguos quando o usuário precisa digitar a chave a partir de um screenshot ou de uma folha impressa.

A URI otpauth e o QR Code de enrollment

Para fazer o onboarding do usuário, o servidor normalmente emite uma URI otpauth:// renderizada como QR Code:

otpauth://totp/Acme:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Acme&algorithm=SHA1&digits=6&period=30

A query string carrega o secret em Base32, o issuer legível, o algoritmo HMAC (SHA-1 é universal; SHA-256 e SHA-512 são permitidos pela RFC mas raramente suportados pelos apps mobile), o número de dígitos (6 por padrão, 8 ocasionalmente) e o passo em segundos (30 por padrão). No lado do servidor, o verificador aceita a janela atual mais uma janela antes e uma depois — essa tolerância de um passo absorve o inevitável drift de relógio entre celular e servidor.

Checklist de hardening

• Gere o secret com CSPRNG (crypto.randomBytes(20) em Node, secrets.token_bytes(20) em Python).
• Mostre o secret uma única vez durante o enrollment; nunca registre em log e nunca grave em texto puro — criptografe at-rest do mesmo jeito que uma chave de hashing de senhas.
• Rejeite um código já consumido na mesma janela de 30 segundos para neutralizar ataques de replay em um terminal comprometido.
• Emita códigos de recuperação únicos no enrollment para o caso de o usuário perder o celular.
• Aplique rate limit no endpoint de verificação — seis dígitos é apenas 1 em 1 milhão, brute force é realista sem throttling.

Viagem e drift de relógio

TOTP depende de relógio UTC sincronizado nas duas pontas; o fuso horário do usuário é irrelevante porque o algoritmo hasheia um contador de passos baseado em UTC. Na prática, problemas só aparecem quando o relógio do celular foi setado manualmente, quando o aparelho ficou offline por dias com cristal fraco ou quando o desktop pulou o sync NTP após o suspend. Se um usuário reporta "o código está sempre errado", verifique antes de qualquer coisa a hora do dispositivo — no servidor, logue o offset de step dos códigos aceitos por alguns dias para identificar dispositivos saindo da janela ±1.

Perguntas frequentes

O app autenticador precisa de internet para gerar os códigos? Não. TOTP é totalmente offline — os dois lados só precisam de relógio sincronizado e do secret compartilhado. Esse é o diferencial em relação a SMS ou e-mail, que dependem de um canal de entrega.

Perdi o celular — dá para recuperar a conta? Apenas com os códigos de recuperação emitidos no enrollment, um reset administrativo ou um canal alternativo. O secret em si não pode ser reconstruído a partir de um código; essa é exatamente a propriedade do HMAC.

TOTP é mesmo melhor que 2FA por SMS? Sim. SMS é vulnerável a SIM swap, interceptação SS7 e phishing do código entregue. TOTP mantém o secret no dispositivo e não transmite nada que possa ser interceptado.

Por que ainda SHA-1 em 2026? A construção HMAC não é afetada pelos ataques de colisão contra SHA-1 (que atingem a hash sem chave). Todos os apps autenticadores suportam SHA-1 universalmente; trocar para SHA-256 quebra a compatibilidade com a maioria dos apps de consumidor sem ganho de segurança mensurável.

O secret gerado aqui é enviado para algum servidor? Não. A geração acontece inteiramente no seu navegador usando crypto.getRandomValues() — nada trafega pela rede.