HOTP

HOTP (HMAC-based One-Time Password, RFC 4226) es la variante basada en contador de TOTP. Donde TOTP avanza en un reloj, HOTP avanza en un contador compartido que tanto el token como el servidor incrementan con cada código usado. HOTP es el modo canónico para YubiKey OATH, tokens de hardware heredados y algunos flujos bancarios donde el servidor no puede confiar en la sincronización del reloj.

Canonical spec:RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm (2005).
URI scheme:Google Authenticator Key URI Format, the otpauth:// scheme every authenticator agrees on.
Sibling spec:TOTP (RFC 6238), time-based variant that builds on HOTP.

Qué es

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, cuándo usar cada uno

Propiedad	HOTP (RFC 4226)	TOTP (RFC 6238)
Avanza en	Contador	Reloj (cada 30 s)
Requiere sincronización de reloj	No	Sí, margen de ~30 s
Resincronización al desvío	El servidor acepta los próximos N valores de contador	El servidor acepta ±1 ventana
Despliegue típico	YubiKey, tokens de hardware heredados, banca offline	Todo 2FA de consumidor, Google, Microsoft, 1Password, Authy
Reutilización del contador	Catastrófico, filtra el secreto con el tiempo	N/A
Vulnerabilidad si el secreto se filtra	Todos los códigos futuros predecibles	Todos los códigos pasados + futuros predecibles

Vectores de prueba canónicos

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

Counter	HOTP (6-digit)
`0`	`755224`
`1`	`287082`
`2`	`359152`
`3`	`969429`
`4`	`338314`
`5`	`254676`
`6`	`287922`
`7`	`162583`
`8`	`399871`
`9`	`520489`

Minimal QR payload for enrolment at counter 0:

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

Validador de secreto Base32 en 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.

Secreto HMAC Base32

Introduce un secreto para validar.

Errores comunes

Desincronización del contador. Si el usuario pulsa el botón del token pero el servidor no registra el código (fallo de red, doble clic), el contador del token va por delante del servidor. Los servidores lo manejan con una "ventana de resincronización", prueban los siguientes N valores de contador antes de rechazar. La ventana predeterminada de YubiKey es ~3; los despliegues de alta seguridad la reducen a 1.
La reutilización del contador es catastrófica. Nunca aceptes el mismo valor de contador dos veces. Si el servidor lo hace, un atacante que husmee un código puede reproducirlo más tarde. RFC 4226 §7.3 exige que el servidor rechace cualquier código igual o inferior al último contador aceptado.
Exportación del contador durante la copia de seguridad. Las apps de autenticación que exportan entradas HOTP a veces exportan el secreto pero no el contador actual. Importar en un nuevo dispositivo reinicia el contador en 0, desincronizado con el servidor, inscripción efectivamente rota. TOTP es inmune; HOTP es frágil aquí.
Base32 no es Base64. Misma regla que TOTP: los secretos con 0, 1, 8, 9, letras minúsculas, + o / son Base64 y serán rechazados por todo autenticador compatible con RFC.
Solo SHA1, en la práctica. RFC 4226 define SHA1 como la función HMAC. SHA256/SHA512 son extensiones de la era TOTP RFC 6238; la mayoría de los tokens de hardware HOTP (incluido YubiKey OATH) no los implementan.
El parámetro de dígitos a menudo se ignora. Muchos tokens de hardware están fijados en 6 dígitos y truncan silenciosamente si pides 8. Verifica con tu hardware objetivo antes de que el QR llegue a tarjetas impresas.
No mezcles HOTP y TOTP en el mismo QR. El esquema URI usa el segmento TYPE (hotp vs totp) para cambiar de modo. Un único secreto puede alimentar ambos, pero eso significa que ambos flujos comparten el secreto, si uno se compromete, ambos fallan.

Compatibilidad de apps de autenticación

App / token	HOTP	SHA256/512	8 dígitos	Notas
YubiKey Authenticator (iOS/Android/escritorio)	Sí	Sí	Sí	HOTP es el modo canónico de YubiKey OATH. Soporte completo RFC 4226.
Google Authenticator	Sí	Ignorado (solo SHA1)	Ignorado (solo 6)	La línea base de facto. Seguro para HOTP pero solo con 6 dígitos SHA1.
1Password	Sí	Sí	Sí	Soporte RFC completo. El contador se almacena y exporta con la entrada.
Bitwarden	Sí	Sí	Sí	Soporte RFC completo.
Microsoft Authenticator	Sí	Sí	Sí	Soporte RFC completo.
Authy	No	,	,	Eliminó HOTP en versiones recientes. Solo TOTP.
Duo Mobile	No	,	,	Usa su propio flujo push; solo TOTP como fallback.
Tokens de hardware OATH (Feitian, Token2, etc.)	Sí	Varía	Varía	Mercado canónico de hardware HOTP; siempre 6 dígitos SHA1 salvo que el datasheet diga lo contrario.

Ver también

/hotp-qr-code/, el generador HOTP con validación de contador + Base32 en vivo.
/standards/totp/, el hermano basado en tiempo (RFC 6238).
/totp-2fa-qr-code/, el generador TOTP.
/standards/, volver al índice de estándares.

Spec references verified Referencias de especificaciones verificadas el