HOTP

HOTP (HMAC-based One-Time Password, RFC 4226) é a variante baseada em contador do TOTP. Onde TOTP avança em um relógio, HOTP avança em um contador compartilhado que tanto o token quanto o servidor incrementam a cada código usado. HOTP é o modo canônico para YubiKey OATH, tokens de hardware legados e alguns fluxos bancários onde o servidor não pode depender de sincronização de relógio.

O que é

An HOTP enrolment QR is a URL in the otpauth:// scheme with hotp as the type. It carries the shared HMAC secret plus a counter value that both sides must keep in sync. Format:

otpauth://hotp/LABEL?secret=SECRET&issuer=ISSUER&counter=N&digits=N&algorithm=ALG

• LABEL, Issuer:Account, URL-encoded. Example: YubiKey:alice@example.com.
• secret, the shared HMAC key, Base32-encoded (RFC 4648 §6: A-Z, 2-7).
• counter, starting counter value. Usually 0, but can be resumed from a known value when re-enrolling a token.
• issuer, the service name shown in the authenticator app.
• digits, 6 (default) or 8. RFC 4226 §5.3 specifies 6; 8 is a common extension.
• algorithm, SHA1 in practice. RFC 4226 only defines SHA1; SHA256/512 variants are RFC 6238 extensions bolted on after-the-fact.

HOTP vs TOTP, quando usar cada um

Vetores de teste canônicos

RFC 4226 Appendix D provides reference HOTP values for the secret 12345678901234567890 (20 bytes, Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ) with 6-digit output:

Minimal QR payload for enrolment at counter 0:

otpauth://hotp/Example:test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example&counter=0

Validador de segredo Base32 ao vivo

Same validator as the TOTP page, HOTP secrets use the identical Base32 alphabet (RFC 4648 §6: A-Z, 2-7). Runs in your browser, no server round-trip.

Armadilhas comuns

• Desvio do contador. Se o usuário pressionar o botão do token mas o servidor não registrar o código (falha de rede, clique duplo), o contador do token fica à frente do servidor. Os servidores lidam com isso com uma "janela de ressincronização", tentam os próximos N valores de contador antes de rejeitar. A janela padrão do YubiKey é ~3; implantações de alta segurança a reduzem para 1.
• A reutilização do contador é catastrófica. Nunca aceite o mesmo valor de contador duas vezes. Se o servidor aceitar, um invasor que capturou um código pode reproduzi-lo depois. RFC 4226 §7.3 exige que o servidor recuse qualquer código no ou abaixo do último contador aceito.
• Exportação do contador durante o backup. Apps de autenticação que exportam entradas HOTP às vezes exportam o segredo mas não o contador atual. Importar em um novo dispositivo reinicia o contador em 0, fora de sincronia com o servidor, inscrição efetivamente quebrada. TOTP é imune; HOTP é frágil aqui.
• Base32 não é Base64. Mesma regra que TOTP: segredos com 0, 1, 8, 9, letras minúsculas, + ou / são Base64 e serão rejeitados por todo autenticador compatível com RFC.
• Somente SHA1, na prática. RFC 4226 define SHA1 como a função HMAC. SHA256/SHA512 são extensões da era TOTP RFC 6238; a maioria dos tokens de hardware HOTP (incluindo YubiKey OATH) não os implementa.
• Parâmetro de dígitos frequentemente ignorado. Muitos tokens de hardware estão fixados em 6 dígitos e truncam silenciosamente se você pedir 8. Verifique com seu hardware alvo antes de o QR chegar a cartões impressos.
• Não misture HOTP e TOTP no mesmo QR. O esquema URI usa o segmento TYPE (hotp vs totp) para mudar de modo. Um único segredo pode alimentar ambos, mas isso significa que ambos os fluxos compartilham o segredo, se um for comprometido, ambos falham.

Compatibilidade de apps de autenticação

Veja também

• /hotp-qr-code/, o gerador HOTP com validação de contador + Base32 ao vivo.
• /standards/totp/, a variante baseada em tempo (RFC 6238).
• /totp-2fa-qr-code/, o gerador TOTP.
• /standards/, voltar ao índice de padrões.

Spec references verified Referências de especificações verificadas em