- A Diferença Fundamental na Entrada: O HOTP calcula hashes a partir de um contador C incremental e monotônico, enquanto o TOTP substitui C por um passo de tempo discreto T (TempoUnixAtual / 30).
- Herança Direta: O TOTP é matematicamente uma especialização do HOTP:
TOTP(K, Tempo) = HOTP(K, T). Ambos os algoritmos empregam exatamente a mesma função de Truncamento Dinâmico (Dynamic Truncation). - Fator Decisivo de Arquitetura: O HOTP possui estado (stateful): os servidores precisam registrar e persistir em disco o avanço de contadores a cada autenticação. O TOTP não possui estado (stateless), permitindo que microsserviços modernos validem tokens em clusters distribuídos com balanceamento de carga sem gravações centralizadas em banco de dados.
Origem Histórica: Dos Tokens Físicos aos Smartphones
No início dos anos 2000, a autenticação corporativa em dois fatores era dominada por tokens físicos proprietários, como o RSA SecurID. Esses chaveiros fechados e caros continham osciladores a quartzo internos sincronizados com servidores corporativos dedicados. Quando uma organização precisava oferecer segurança multifator a milhares de funcionários, o custo de aquisição de hardware e licenciamento era estratosférico.
Para libertar o mercado dos ecossistemas proprietários, o consórcio OATH (Initiative for Open Authentication) reuniu gigantes da indústria para conceber padrões IETF abertos e livres de royalties, que qualquer engenheiro pudesse inspecionar, auditar e implementar:
Algoritmo de Senha de Uso Único Baseada em HMAC. Projetado para microcontroladores de baixo consumo com botão físico. Cada toque incrementa um contador interno e projeta um token de 6 dígitos em visor LCD.
Algoritmo de Senha de Uso Único Baseada em Tempo. Criado no auge da ascensão dos smartphones. Ao aproveitar a sincronização precisa de relógio via rede celular NTP, eliminou de vez as dessincronizações de botões físicos.
HOTP (RFC 4226) & Truncamento Dinâmico de Bytes
A formulação matemática fundamental do HOTP é notavelmente concisa:
Detalhamento dos Parâmetros:
K: Chave secreta simétrica compartilhada (geralmente decodificada de Base32 para uma sequência binária de 160 bits / 20 bytes).C: Contador inteiro de 8 bytes (64 bits) em formato big-endian.HMAC-SHA-1: Código de autenticação de mensagem baseado em hash criptográfico gerando digest de 20 bytes (160 bits).
🔍 Como o Truncamento Dinâmico (DT) Converte 20 Bytes em 6 Dígitos:
Um digest HMAC-SHA1 possui 160 bits (20 bytes). Extrair 6 dígitos decimais uniformes exige um algoritmo determinístico e resistente a colisões, estipulado na Seção 5.3 da RFC 4226:
Suponha que a chave secreta seja a string ASCII "12345678901234567890" e o contador seja C = 0. O digest HMAC-SHA1 resultante em hexadecimal é:
1. O byte final é 0x71. Fazendo 0x71 & 0x0F = 0x01, obtém-se Offset = 1.
2. Os bytes do índice 1 ao 4 são: 93 cf 18 50. Zerando o bit de sinal mais alto resulta em 0x13cf1850, que em decimal equivale a 332.339.280.
3. Calculando 332339280 mod 1000000 = 339280. O código final de 6 dígitos gerado é exatamente 339280!
Evolução para o TOTP (RFC 6238): O Passo Temporal
O HOTP exigia manter o contador do cliente rigidamente sincronizado com o servidor. Em dispositivos com software, contar toques ou cliques causava constantes falhas humanas e descompassos.
A RFC 6238 substituiu o contador de eventos C por um passo temporal discreto T calculado a partir do relógio Unix Epoch:
- TempoUnixAtual: Número de segundos decorridos desde 01-01-1970 00:00:00 UTC.
- T0: Referência de início de época (padronizado em 0 em todas as implementações atuais).
- X (Janela Temporal / Time Step): Intervalo de tempo recomendado de 30 segundos.
- Função Piso ⌊ ⌋: Para qualquer segundo dentro da janela de 30 segundos, T permanece rigorosamente constante. Por exemplo, entre os segundos de época 1728211200 e 1728211229, o valor de T avalia exatamente para o mesmo número inteiro de 64 bits.
Serialização Binária: Uma vez calculado T, ele é serializado em um buffer de 8 bytes em big-endian (idêntico à estrutura do contador C no HOTP). Por isso, a fórmula unificada resume-se a:
TOTP(K, Tempo) = HOTP(K, T)
Essa elegância matemática explica por que os aplicativos autenticadores renovam códigos sincronizadamente a cada 30 segundos sem qualquer necessidade de salvar contadores em disco.
HS[31] & 0x0F); no SHA-512 (digest de 64 bytes), o offset é retirado no byte 63 (HS[63] & 0x0F). Entretanto, em 99,9% dos sites corporativos (Google, Microsoft, GitHub, AWS), o SHA-1 permanece como padrão universal por questões de compatibilidade histórica de clientes móveis.
Matriz Comparativa Completa Lado a Lado (HOTP vs. TOTP)
| Dimensão | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Variável de Entrada | Contador de eventos C (incremental e monotônico) | Passo de tempo T (janela Unix Epoch de 30 segundos) |
| Validade do Token | Indefinida (válido até ser consumido no próximo login) | Estrita de 30 segundos (expira automaticamente) |
| Arquitetura de Servidor | Com Estado / Stateful (requer gravação atômica em BD por login) | Sem Estado / Stateless (validação independente via NTP) |
| Exposição a Ataque de Replay | Moderada (código interceptado é válido até o uso) | Mínima (restrita aos segundos restantes da janela atual) |
| Principal Modo de Falha | Dessincronização de Contador (cliques acidentais) | Desvio de Relógio (Clock Drift no smartphone) |
| Hashes Suportados | HMAC-SHA-1 exclusivamente | HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 |
| Adoção no Mercado | Tokens bancários legados e catracas industriais | 99,9% dos autenticadores modernos da web |
Dessincronização vs. Desvio de Relógio: Mitigações de Engenharia
Em sistemas de produção distribuídos, clientes e servidores sofrem variações naturais. Os criadores dos protocolos estabeleceram janelas de tolerância explícitas:
Se um usuário apertar o botão do chaveiro 5 vezes sem fazer login, o contador do aparelho atinge C+5 enquanto o servidor continua em C.
A RFC 4226 estipula que o servidor teste uma janela prospectiva entre [C+1, C+s] (geralmente s=20). Havendo correspondência, o servidor avança seu contador imediatamente para ressincronizar com o cliente.
Latência de rede e desvios de relógio de hardware (por exemplo, um celular com 10 segundos de atraso) fazem o código chegar na janela vizinha.
Servidores de produção avaliam um array de 3 janelas: [T-1, T, T+1], expandindo a janela total de aceitação para 90 segundos.
Ao comparar o código enviado pelo usuário com o calculado no servidor, comparações de string ingênuas (como codigoUsuario === codigoServidor) abortam no primeiro caractere divergente. Atacantes com cronômetros de rede de altíssima precisão conseguem deduzir dígitos medindo microssegundos de resposta. Backends corporativos exigem comparações em tempo constante (como crypto.timingSafeEqual no Node.js) para frustrar ataques de canal lateral (side-channel).
Por que o TOTP Dominou a Internet Moderna
A vitória decisiva do TOTP sobre o HOTP em escala global ocorreu por três imperativos de arquitetura:
Em microsserviços distribuídos em várias regiões, qualquer servidor com relógio NTP sincronizado valida tokens TOTP sem travar nem consultar bancos de dados centralizados.
Smartphones calibram a hora continuamente via antenas celulares e GPS, eliminando falhas de desvio de relógio sem requerer manutenção física de aparelhos.
Tokens HOTP continuam válidos indefinidamente até o próximo uso. Códigos TOTP expiram em 30 segundos, neutralizando vazamentos em logs e capturas de pacotes automaticamente.
Experimente os Cálculos TOTP em Tempo Real no 2FA-Tool
Veja na prática como sua semente secreta Base32 se transforma em códigos dinâmicos de 6 dígitos via truncamento dinâmico HMAC-SHA1. Totalmente offline no seu navegador.
📚 Guias de Segurança Relacionados
Como transferir contas 2FA para novos celulares com QR Code offline e Cloud Sync.
Conformidade obrigatória, armazenamento seguro de códigos de emergência e resgate.
Como recuperar o acesso a contas Google, Microsoft, Steam, Binance, Apple e Discord.