HOTP

HOTP (HMAC-based One-Time Password, RFC 4226) è la variante basata su contatore di TOTP. Dove TOTP avanza su un orologio, HOTP avanza su un contatore condiviso che sia il token che il server incrementano a ogni codice usato. HOTP è il modo canonico per YubiKey OATH, token hardware legacy e alcuni flussi bancari dove il server non può fare affidamento sulla sincronizzazione dell'orologio.

Cos'è

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 usare quale

Vettori di test canonici

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

Validatore di segreto Base32 live

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.

Insidie comuni

• Deriva del contatore. Se l'utente preme il pulsante del token ma il server non registra il codice (interruzione di rete, doppio clic), il contatore del token supera quello del server. I server gestiscono questo con una "finestra di risincronizzazione", provano i successivi N valori del contatore prima di rifiutare. La finestra predefinita di YubiKey è ~3; i deployment ad alta sicurezza la restringono a 1.
• Il riutilizzo del contatore è catastrofico. Non accettare mai lo stesso valore del contatore due volte. Se il server lo fa, un attaccante che ha intercettato un codice può riprodurlo in seguito. RFC 4226 §7.3 impone che il server rifiuti qualsiasi codice pari o inferiore all'ultimo contatore accettato.
• Esportazione del contatore durante il backup. Le app di autenticazione che esportano le voci HOTP a volte esportano il segreto ma non il contatore corrente. L'importazione su un nuovo dispositivo riparte dal contatore a 0, fuori sincronia con il server, iscrizione effettivamente rotta. TOTP è immune; HOTP è fragile qui.
• Base32 non è Base64. Stessa regola di TOTP: segreti con 0, 1, 8, 9, lettere minuscole, + o / sono Base64 e verranno rifiutati da ogni autenticatore conforme RFC.
• Solo SHA1, in pratica. RFC 4226 definisce SHA1 come funzione HMAC. SHA256/SHA512 sono estensioni dell'era TOTP RFC 6238; la maggior parte dei token hardware HOTP (incluso YubiKey OATH) non le implementa.
• Il parametro digits spesso ignorato. Molti token hardware sono fissi a 6 cifre e troncano silenziosamente se chiedi 8. Verifica con il tuo hardware target prima che il QR arrivi su tessere stampate.
• Non mescolare HOTP e TOTP nello stesso QR. Lo schema URI usa il segmento TYPE (hotp vs totp) per cambiare modalità. Un unico segreto può alimentare entrambi, ma ciò significa che entrambi i flussi condividono il segreto, se uno viene compromesso, entrambi falliscono.

Compatibilità delle app di autenticazione

Vedi anche

• /hotp-qr-code/, il generatore HOTP con validazione contatore + Base32 live.
• /standards/totp/, la variante basata sul tempo (RFC 6238).
• /totp-2fa-qr-code/, il generatore TOTP.
• /standards/, torna all'indice degli standard.

Spec references verified Riferimenti alle specifiche verificati il