HOTP

HOTP (รหัสผ่านแบบใช้ครั้งเดียวอ้างอิง HMAC, RFC 4226) คือพี่น้องอ้างอิงตัวนับของ TOTP ขณะที่ TOTP ดำเนินตามนาฬิกา HOTP จะดำเนินตามตัวนับร่วมที่ทั้ง token และ server เพิ่มขึ้นทุกครั้งที่ใช้มา HOTP คือโหมดมาตรฐานสำหรับ YubiKey OATH, hardware token รุ่นเก่า และบางขั้นตอนของธนาคารที่ server ไม่สามารถพึ่งการซิงค์นาฬิกาได้

เอกสารข้อกำหนด: RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm (2005).
URI scheme: Google Authenticator Key URI Format, scheme otpauth:// ที่ทุกแอปยืนยันตัวตนยอมรับ
ข้อกำหนดที่เกี่ยวข้อง: TOTP (RFC 6238), ตัวแปรอ้างอิงเวลาที่สร้างบน HOTP

ภาพรวม

QR ลงทะเบียน HOTP คือ URL ใน scheme otpauth:// ที่มี hotp เป็นประเภท บรรจุ shared HMAC secret พร้อมค่า ตัวนับ ที่ทั้งสองฝ่ายต้องซิงค์ รูปแบบ:

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

LABEL, Issuer:Account, URL-encoded ตัวอย่าง: YubiKey:alice@example.com
secret, คีย์ HMAC ที่ใช้ร่วมกัน เข้ารหัส Base32 (RFC 4648 §6: A-Z, 2-7)
counter, ค่าตัวนับเริ่มต้น โดยทั่วไปคือ 0 แต่สามารถดำเนินต่อจากค่าที่ทราบเมื่อลงทะเบียนใหม่
issuer, ชื่อบริการที่แสดงในแอปยืนยันตัวตน
digits, 6 (ค่าเริ่มต้น) หรือ 8 RFC 4226 §5.3 กำหนด 6; 8 เป็นส่วนขยายทั่วไป
algorithm, SHA1 ในทางปฏิบัติ RFC 4226 กำหนดเฉพาะ SHA1; SHA256/512 เป็นส่วนขยาย RFC 6238 ที่เพิ่มในภายหลัง

HOTP vs TOTP, ควรใช้อะไร

คุณสมบัติ	HOTP (RFC 4226)	TOTP (RFC 6238)
ดำเนินตาม	ตัวนับ (การใช้งานที่สำเร็จแต่ละครั้ง)	นาฬิกา (ทุก 30 วินาที)
ต้องการการซิงค์นาฬิกา	ไม่	ใช่ ภายใน ~30 วินาที
ซิงค์ใหม่เมื่อเบี่ยงเบน	Server ยอมรับค่าตัวนับ N ค่าถัดไป	Server ยอมรับ ±1 หน้าต่าง
การใช้งานทั่วไป	YubiKey, hardware token รุ่นเก่า, ธนาคารออฟไลน์	2FA ผู้บริโภคทุกประเภท, Google, Microsoft, 1Password, Authy
การใช้ตัวนับซ้ำ	หายนะ, เปิดเผย secret เมื่อเวลาผ่านไป	ไม่เกี่ยวข้อง
ช่องโหว่หาก secret รั่ว	รหัสอนาคตทั้งหมดทำนายได้	รหัสอดีตและอนาคตทั้งหมดทำนายได้

Test vector มาตรฐาน

RFC 4226 ภาคผนวก D ให้ค่า HOTP อ้างอิงสำหรับ secret 12345678901234567890 (20 ไบต์, Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ) พร้อมเอาต์พุต 6 หลัก:

ตัวนับ	HOTP (6 หลัก)
`0`	`755224`
`1`	`287082`
`2`	`359152`
`3`	`969429`
`4`	`338314`
`5`	`254676`
`6`	`287922`
`7`	`162583`
`8`	`399871`
`9`	`520489`

Payload QR ขั้นต่ำสำหรับการลงทะเบียนที่ตัวนับ 0:

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

ตัวตรวจสอบ secret Base32 สด

ตัวตรวจสอบเดียวกับหน้า TOTP, secret ของ HOTP ใช้ตัวอักษร Base32 เดียวกัน (RFC 4648 §6: A-Z, 2-7) ทำงานในเบราว์เซอร์ ไม่ต้องไปที่ server

HMAC secret Base32

ใส่ secret เพื่อตรวจสอบ

จุดที่มักพลาด

ตัวนับเบี่ยงเบน. ถ้าผู้ใช้กดปุ่ม token แต่ server ไม่บันทึกมา (ปัญหาเครือข่าย, คลิกสองครั้ง) ตัวนับ token จะวิ่งล้ำหน้าตัวนับ server เซิร์ฟเวอร์จัดการด้วย "หน้าต่างซิงค์ใหม่" โดยลองค่าตัวนับ N ค่าถัดไปก่อนปฏิเสธ หน้าต่างเริ่มต้นของ YubiKey คือ ~3; การใช้งานที่ความปลอดภัยสูงจะแคบลงเป็น 1
การใช้ตัวนับซ้ำเป็นหายนะ. อย่ายอมรับค่าตัวนับเดิมสองครั้ง RFC 4226 §7.3 บังคับให้ server ปฏิเสธมาทุกโค้ดที่เท่ากับหรือต่ำกว่าตัวนับที่ยอมรับครั้งล่าสุด
การส่งออกตัวนับระหว่างสำรองข้อมูล. แอปยืนยันตัวตนที่ส่งออก HOTP บางตัวส่งออก secret แต่ไม่ส่งออกตัวนับปัจจุบัน การนำเข้าไปยังอุปกรณ์ใหม่จะเริ่มตัวนับจาก 0 ไม่ตรงกับ server ทำให้การลงทะเบียนหายไปจริง ๆ TOTP ไม่มีปัญหานี้ แต่ HOTP เปราะบาง
Base32 ไม่ใช่ Base64. กฎเดียวกับ TOTP: secret ที่มี 0, 1, 8, 9, ตัวพิมพ์เล็ก, + หรือ / คือ Base64 และทุกแอปที่เป็น RFC จะปฏิเสธ
SHA1 เท่านั้นในทางปฏิบัติ. RFC 4226 กำหนด SHA1 เป็นฟังก์ชัน HMAC hardware token HOTP ส่วนใหญ่ (รวมถึง YubiKey OATH) ไม่ใช้งาน SHA256/SHA512
พารามิเตอร์ digits มักถูกเพิกเฉย. hardware token หลายตัวล็อกที่ 6 หลักและตัดอย่างเงียบถ้าคุณขอ 8 ให้ตรวจสอบกับ hardware เป้าหมายก่อนที่ QR จะถึงการ์ดพิมพ์
อย่าผสม HOTP และ TOTP ใน QR เดียว. URI scheme ใช้เซกเมนต์ TYPE (hotp vs totp) เพื่อสลับโหมด secret หนึ่งสามารถขับเคลื่อนทั้งสองขั้นตอน แต่นั่นหมายความว่าทั้งสองขั้นตอนแชร์ secret ถ้าอันหนึ่งถูกโจมตีทั้งสองล้มเหลว

ความเข้ากันได้ของแอปยืนยันตัวตน

แอป / token	HOTP	SHA256/512	8 หลัก	หมายเหตุ
YubiKey Authenticator (iOS/Android/desktop)	ใช่	ใช่	ใช่	HOTP คือโหมดมาตรฐาน YubiKey OATH รองรับ RFC 4226 ครบถ้วน
Google Authenticator	ใช่	ไม่สนใจ (SHA1 เท่านั้น)	ไม่สนใจ (6 เท่านั้น)	มาตรฐาน de facto ปลอดภัยสำหรับ HOTP แต่เฉพาะ 6 หลัก SHA1
1Password	ใช่	ใช่	ใช่	รองรับ RFC ครบถ้วน ตัวนับถูกเก็บและส่งออกพร้อมกับ entry
Bitwarden	ใช่	ใช่	ใช่	รองรับ RFC ครบถ้วน
Microsoft Authenticator	ใช่	ใช่	ใช่	รองรับ RFC ครบถ้วน
Authy	ไม่	,	,	ตัดออก HOTP ในเวอร์ชันล่าสุด เฉพาะ TOTP
Duo Mobile	ไม่	,	,	ใช้ push flow ของตัวเอง เฉพาะ TOTP fallback
OATH hardware tokens (Feitian, Token2 ฯลฯ)	ใช่	แตกต่างกัน	แตกต่างกัน	ตลาด hardware HOTP มาตรฐาน เสมอ 6 หลัก SHA1 เว้นแต่ datasheet จะระบุไว้

ดูเพิ่มเติม

/hotp-qr-code/, ตัวสร้าง HOTP พร้อมตัวนับสดและการตรวจสอบ Base32
/standards/totp/, ตัวแปรอ้างอิงเวลา (RFC 6238)
/totp-2fa-qr-code/, ตัวสร้าง TOTP
/standards/, กลับไปที่ดัชนีมาตรฐาน

ตรวจสอบอ้างอิงข้อกำหนด 2026-04-19. RFC 4226 (2005), Google Key URI Format.