TOTP

TOTP (Senha de Uso Único Baseada em Tempo) é o algoritmo por trás do Google Authenticator, Authy, do recurso TOTP do 1Password e da maioria dos 2FA baseados em software. Definido em RFC 6238 (2011).

Como funciona: no cadastro, o servidor e o aplicativo autenticador trocam um segredo compartilhado (tipicamente um valor de 160 bits codificado como uma string base32 ou QR code). Para gerar o OTP atual, ambos os lados:

1. Pegam o tempo Unix atual, dividido pelo período (padrão 30 segundos), arredondado para baixo.
2. Calculam HMAC-SHA1 desse contador usando o segredo compartilhado.
3. Truncam para 6 dígitos.

Ambos os lados produzem o mesmo código sem se comunicar. A janela de 30 segundos mais uma tolerância de ±1 janela trata a deriva de relógio. O segredo compartilhado nunca sai do dispositivo após o cadastro.

TOTP é enormemente melhor que SMS OTP (sem exposição a troca de SIM), mas não derrota phishing por si só — um atacante que phisha o código atual pode reproduzi-lo dentro da janela. WebAuthn / passkeys são a resposta de próxima geração.

O formato de provisionamento do segredo compartilhado: os QR codes mostrados pelo Google Authenticator, GitHub, AWS IAM e outros codificam um URI otpauth://totp/Emissor:rótulo?secret=BASE32SECRET&algorithm=SHA1&digits=6&period=30. O esquema é uma convenção do Google de 2011 em vez de uma especificação IETF formal, mas todos os principais aplicativos autenticadores o suportam. Alguns serviços (Microsoft, Steam) estendem os dígitos para 7-8 ou encurtam o período para 15 segundos para maior entropia ao custo de uma janela mais apertada. Leia o QR com um aplicativo de leitura de QR genérico uma vez para capturar o segredo, depois faça backup offline — perder o acesso ao autenticador sem esse backup significa passar pela recuperação de conta.

SHA-1 em uma especificação de 2026 — é seguro? Sim, neste contexto. O uso de HMAC-SHA1 pelo TOTP não é vulnerável aos ataques de colisão do SHA-1 que aposentaram o hash para certificados TLS; HMAC depende da resistência de pré-imagem do SHA-1, que permanece intacta. RFC 6238 também permite SHA-256 e SHA-512, mas praticamente todos os aplicativos autenticadores usam SHA-1 por padrão para compatibilidade entre fornecedores. Se o URI de provisionamento especificar algorithm=SHA256, o verificador e o autenticador devem ambos suportá-lo — muitos aplicativos mais antigos silenciosamente quebrarão. Relacionado: OTP, SHA-256, JWT.

Exemplo prático: derivando um código

Segredo compartilhado (base32) JBSWY3DPEHPK3PXP. Suponha que o tempo Unix atual seja 1700000000. Contador = piso(1700000000 / 30) = 56666666. Empacote o contador como um inteiro de 8 bytes big-endian, calcule HMAC-SHA1(segredo, contador) produzindo um digest de 20 bytes, pegue o nibble de ordem baixa do último byte como deslocamento o, leia 4 bytes a partir de o, mascare o bit alto e aplique mod 10⁶. O resultado é um código de 6 dígitos como 359152. Em t = 1700000030 o contador avança em 1 e o código rotaciona. Doze segundos de desvio de relógio entre servidor e telefone são inofensivos; sessenta segundos geralmente falham na verificação a menos que o servidor amplie a janela de tolerância.

Quando TOTP é a escolha certa

TOTP faz sentido como segundo fator em qualquer lugar onde um atacante que já tem a senha ainda deve ser bloqueado: logins bancários, hospedagem de código, consoles na nuvem, e-mail. Ele não substitui uma senha (o segredo é simétrico — o comprometimento do servidor revela a semente de cada usuário) e não para kits de phishing em tempo real como evilginx que fazem proxy do fluxo de login. Para autenticação resistente a phishing, prefira WebAuthn / passkeys, que vinculam criptograficamente a credencial à origem legítima. Referência: NIST SP 800-63B — Diretrizes de Identidade Digital (Autenticação), que categoriza TOTP como um autenticador AAL2 de “algo que você tem” equivalente a segredo memorizado.