search

Found

info Visão geral

Calcule códigos HOTP HMAC-SHA-1 de 6, 7 ou 8 dígitos a partir de um segredo Base32 e contador, e verifique se um código enviado bate dentro da janela ±N.

📘 Como usar

  1. Informe o segredo compartilhado em Base32 e o valor do contador
  2. Escolha o número de dígitos (6/7/8) e a janela de validação ±N
  3. Digite um código recebido para ver se bate dentro da janela

Validador de contador HOTP (RFC 4226)

Base32 RFC 4648 (A-Z e 2-7). Espaços e hífens são ignorados.

Valor C de RFC 4226 §5.3. Inteiro não negativo; HOTP avança por contador, não por tempo.

Tamanho do OTP. Google Authenticator usa 6 dígitos; Yubico geralmente 8.

Faixa ±N (0-10) ao redor do contador. Pela RFC §7.4 o servidor não deve aceitar C ≤ a um já validado.

Se você digitar o OTP recebido, a correspondência dentro da janela aparece em verde.

HOTP do contador atual

Códigos na janela

Desvio Contador Código
Copiado!

※ HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10^d. C é big-endian de 8 bytes; os 4 bits finais dão um offset cujos 4 bytes (bit alto zerado) entram no módulo.

※ Os servidores toleram desvio ±N e avançam C para o valor coincidente + 1 após login bem-sucedido (RFC §7.4).

Article

Validador de contador HOTP (RFC 4226)|Teste janelas de desvio ±N no navegador

Gere códigos HOTP HMAC-SHA-1 a partir de um segredo Base32 e um contador, e verifique se um código recebido cai dentro da janela ±N. Reproduza o comportamento da RFC 4226 apenas com seus dados, sem precisar de servidor.

💡 Sobre esta ferramenta

HOTP (RFC 4226) é um esquema de senha de uso único cujo fator móvel é um contador, e não o relógio. Ele sustenta tokens físicos como o slot OATH-HOTP da Yubico e códigos por contador que reforçam o SMS. Como dispensa sincronização de horário, encaixa em dispositivos offline e em ambientes onde a hora não é confiável.

O problema clássico do OTP por contador é a dessincronização. O contador do token avança a cada toque no botão, mas o do servidor só avança após um login bem-sucedido. Um usuário que aciona o token à toa desalinha os dois, e os códigos param de validar. A RFC 4226 absorve isso com uma janela de antecipação: o servidor recalcula os próximos valores HOTP, compara com o recebido e, ao bater, ajusta seu contador para o valor coincidente + 1.

Esta ferramenta exibe todos os códigos da janela de uma vez. A linha do contador atual fica destacada e a linha que bate com o código recebido aparece em outra cor, de modo que você pode raciocinar sobre até que desvio um servidor deveria aceitar, ou depurar um token, sem subir um backend. Ela é propositalmente separada do TOTP baseado em tempo: use uma ferramenta TOTP quando o fator móvel for o relógio.

🧐 Perguntas frequentes

Qual a diferença entre HOTP e TOTP? O fator móvel. HOTP usa um contador de eventos; TOTP usa o tempo. Um código HOTP permanece válido até ser usado, ao passo que um TOTP expira sozinho após 30 a 60 segundos. Esta ferramenta trata apenas de HOTP.

Em que formato vai o segredo compartilhado? Base32 da RFC 4648 (A–Z e 2–7). Espaços e hífens são ignorados e o preenchimento = final é opcional. Qualquer caractere inválido em Base32 gera um erro.

O que significa a janela ±N? A faixa de códigos verificada dos dois lados do contador atual. Um N maior tolera mais desvio, mas amplia a superfície de força bruta. A RFC §7.4 recomenda rejeitar todo contador igual ou inferior a um já aceito.

Qual número de dígitos escolher? O tamanho do OTP. O Google Authenticator usa 6 dígitos; os tokens da Yubico costumam usar 8. Acompanhe a especificação do seu token.

Onde o cálculo acontece? Inteiramente no seu navegador pela Web Crypto API; o segredo compartilhado que você digita nunca é enviado a um servidor.

📚 A truncagem dinâmica passo a passo

O coração do HOTP é a truncagem dinâmica. A saída do HMAC-SHA-1 tem 20 bytes; seus últimos 4 bits são lidos como um deslocamento (offset). A partir dessa posição extraem-se 4 bytes e zera-se o bit mais alto, formando um inteiro de 31 bits antes do módulo. Esse zeramento do bit alto não é enfeite: evita que algumas implementações tratem o trecho como inteiro com sinal e cheguem a outro resultado. Por fim, toma-se o resto da divisão desse inteiro por 10 elevado ao número de dígitos. O Apêndice D da RFC 4226 fixa vetores de teste — o segredo 12345678901234567890 gera 755224 no contador 0 e 287082 no contador 1 — que permitem conferir cada etapa. Como o procedimento está congelado com essa precisão, um token e um servidor de fabricantes diferentes chegam ao mesmo código, e o TOTP posterior apenas reaproveitou a mesma truncagem sobre um contador derivado do tempo.