

รหัสจากแอป authenticator ที่เปลี่ยนเป็นช่วงๆ ทำให้เรายืนยันตัวตนเพิ่มจาก password ได้ แต่ตัวเลขบนจอเป็นเพียงผลปลายทางของการคำนวณ ยังมีทั้งกุญแจร่วม เวลาและกติกาฝั่งตรวจที่ทำให้มันมีความหมาย
เมื่อรหัสถูกปฏิเสธ สาเหตุอาจเป็นเวลาไม่ตรง เลือกบัญชีผิดหรือระบบตั้งพารามิเตอร์ต่างกัน ส่วนการยอมรับรหัสได้ก็ยังต้องดูว่าป้องกันการใช้ซ้ำและจำกัดการลองครบตามสัญญาหรือไม่
จึงควรมอง TOTP เป็นวงจรของ authenticator กับ verifier ครับ ไม่จบที่สร้าง QR ให้แอปแสดงตัวเลขได้แล้วถือว่าระบบยืนยันตัวตนทำครบทุกด้าน
TOTP ขยายแนวคิด HOTP โดยใช้ค่าที่อิงเวลาเป็น moving factor ทั้งฝั่งสร้างกับฝั่งตรวจต้องใช้ secret และพารามิเตอร์ที่ตรงกัน เช่น time step กับรายละเอียดอัลกอริทึมตามสัญญาที่รองรับ
เมื่ออยู่ใน time step เดียวกัน ค่าที่สร้างตามเงื่อนไขเดียวกันก็ยังเป็นรหัสเดิม ไม่ใช่การสุ่มรหัสใหม่ทุกครั้งที่เปิดหน้าจอ และไม่ได้จำเป็นต้องมี server ส่งรหัสใหม่มาที่แอปในทุกช่วง
Secret จึงสำคัญกว่าตัวเลขที่มองเห็นชั่วคราว หากคัดลอก secret ไปยังอีกที่ ก็มีความสามารถสร้างรหัสของตัวตนนั้นได้ตามกลไก ต้องเก็บและส่งมอบตามขอบเขตที่ตั้งใจ ไม่มอง QR ตอนลงทะเบียนเป็นเพียงรูปที่แนบในแชทช่วยเหลือได้ตามปกติ
ฝั่ง verifier จำเป็นต้องใช้ secret ตามหน้าที่การคำนวณ จึงมีรูปแบบดูแลข้อมูลต่างจาก password hash ที่ใช้ตรวจแบบไม่ต้องอ่านรหัสเดิม ไม่ควรเปลี่ยน secret เป็น hash ทางเดียวแล้วหวังว่าจะยังคำนวณ TOTP เดิมได้ตาม API โดยไม่ดูสัญญา

Time step กำหนดวิธีแบ่งเวลาสำหรับการคำนวณ ส่วน validation window เป็นนโยบายของผู้ตรวจว่าจะรับช่วงรอบใดบ้างเพื่อรองรับความคลาดของเวลาและระยะส่งข้อมูล การใช้ค่าช่วงสร้างเหมือนกันจึงยังต้องเลือกช่วงตรวจให้เหมาะสมแยกอีกขั้น
ตัวอย่างสถานการณ์สมมติคือผู้ใช้กรอกใกล้จบรอบ แล้วคำขอไปถึงหลังเปลี่ยนรอบแล้ว หาก verifier ตรวจเฉพาะค่าของจังหวะรับอย่างเดียว อาจปฏิเสธทั้งที่ผู้ใช้กรอกจากแอปถูกต้องในจังหวะก่อนหน้า
การยอมรับรอบข้างเคียงช่วยรับมือกรณีที่นโยบายอนุญาต แต่การขยายมากก็เพิ่มขอบเขตรหัสที่อาจผ่านได้ ไม่ควรแก้ปัญหานาฬิกาผิดมากด้วยการยอมรับช่วงกว้างขึ้นเรื่อยๆ โดยไม่ตามต้นเหตุของเวลา
ต้องดูด้วยว่าสองฝ่ายอ้างเวลาพื้นฐานตรงกัน ไม่ปรับ timezone ของหน้าจอมาใช้เป็นตัวเลื่อน moving factor เองตามความรู้สึก การตั้งระบบให้ sync เวลากับการแสดงเวลาท้องถิ่นมีหน้าที่ต่างกัน
มาตรฐาน TOTP ระบุว่าผู้ตรวจต้องไม่รับ OTP เดิมเป็นความสำเร็จครั้งที่สองหลังจากใช้ผ่านไปแล้วภายในช่วงที่เกี่ยวข้อง เพราะตัวรหัสยังอาจเหมือนเดิมตลอด time step ตามกลไกการสร้าง
การเช็กว่าตัวเลขตรงกับรอบที่อนุญาตอย่างเดียวจึงยังไม่ครบ ต้องมีสถานะที่บอกว่าความสำเร็จนั้นถูกใช้ไปแล้วตามขอบเขตของตัวตนกับรอบ และจัดการการอัปเดตให้ไม่เปิดช่องสองคำขอผ่านพร้อมกันจากการอ่านสถานะก่อนเขียน
ถ้ามี verifier หลาย instance สถานะป้องกันใช้ซ้ำต้องสอดคล้องกับเส้นทางรับคำขอด้วย ไม่เก็บเฉพาะหน่วยความจำของแต่ละ process แล้วปล่อยให้การสลับ instance กลายเป็นการเริ่มประวัติใหม่
ขณะเดียวกัน ขั้นหลังตรวจสำเร็จ เช่น การสร้าง session ต้องมีขอบเขตที่ชัด หากบางขั้นล้มเหลว แอปต้องรู้ว่าจะรายงานและให้ผู้ใช้ทำต่ออย่างไรตามนโยบาย โดยไม่คืนสิทธิ์ใช้รหัสเดิมแบบเดาๆ จนลดกติกาป้องกัน replay ของระบบ

OTP ที่คนกรอกมีจำนวนความเป็นไปได้จำกัดเมื่อเทียบกับกุญแจภายใน การเปิดให้ลองได้ไม่จำกัดจึงไม่เหมาะ แม้รหัสจะเปลี่ยนตามเวลา ต้องมีการจำกัดความพยายามฝั่ง verifier ตามบัญชีและบริบทที่เกี่ยวข้อง ไม่พึ่งเพียงปุ่มนับถอยหลังบนหน้าเว็บ
การจำกัดต้องรักษาความหมายเมื่อคำขอมาจากหลายจุดและหลาย instance รวมถึงมีวิธีจัดการเมื่อผู้ใช้จริงถูกจำกัด ไม่ออกแบบให้ใครก็ทำให้บัญชีคนอื่นล็อกไม่สิ้นสุดโดยไม่มีทางรับมือ
ควรใช้ library หรือระบบยืนยันตัวตนที่รองรับมาตรฐานและมีการดูแล แล้วตั้งนโยบายรอบ เวลาและข้อจำกัดให้ตรง ไม่สร้างวิธีตัดเลขหรือคำนวณ secret ขึ้นเองเพียงเพื่อให้หน้าตาเหมือนรหัสจากแอปที่คุ้นเคย
Transport ที่รับ OTP ก็ต้องป้องกันอย่างเหมาะสม และไม่บันทึก OTP หรือ secret ลง log การวิเคราะห์ควรใช้เหตุผลปฏิเสธระดับที่จำเป็นต่อเจ้าของระบบ โดยไม่ให้รายละเอียดช่วยแยกข้อมูลรับรองของผู้ใช้อื่นออกมาจากหน้าสาธารณะ
ขั้นเพิ่ม authenticator ใหม่ต้องยืนยันตามระดับที่ระบบกำหนด ไม่ให้ผู้ที่ได้เพียง session ชั่วคราวเปลี่ยนไปใช้ secret ของตนเองได้โดยไม่มีการตรวจเพิ่มตามนโยบายที่ออกแบบไว้
เมื่อต้องเลิกใช้เครื่องเก่า ต้องมีทางยกเลิกการผูกเดิมและทดสอบว่าความสามารถนั้นหมดผลจริง การลบรายการในแอปบนโทรศัพท์ไม่ได้ลบ secret ที่ verifier ยอมรับหรือสำเนาที่มีคนเก็บไว้เอง
วิธีกู้บัญชีก็ต้องมีการป้องกันที่สัมพันธ์กับสิทธิ์ หาก bypass TOTP ได้เพียงตอบข้อมูลที่หาได้ง่ายจากภายนอก การเพิ่มขั้น OTP ในทางเข้าปกติก็อาจไม่ให้การป้องกันตามที่ผู้ใช้คาด ควรทดสอบทั้งลงทะเบียน ใช้ ยกเลิกและกู้กับบัญชีทดลอง
TOTP แบบที่ผู้ใช้คัดลอกตัวเลขกรอกยังไม่ใช่กลไกทน phishing ตามนิยามของ NIST เพราะหน้าปลอมอาจส่งต่อรหัสไปยัง verifier จริงได้ การมี factor เพิ่มจึงต้องอธิบายขอบเขตให้ตรง ไม่สัญญาว่ากันการหลอกทุกชนิดแล้ว
TOTP ทำงานได้จาก secret เวลาและพารามิเตอร์ที่ตรงกัน แต่ความปลอดภัยยังต้องมีช่วงยอมรับที่เหมาะสม การกันใช้ซ้ำและการจำกัดความพยายาม เมื่อวางวงจรเพิ่มเปลี่ยนยกเลิกกับกู้บัญชีร่วมกัน เราจะใช้รหัสที่เปลี่ยนตามเวลาเป็นส่วนหนึ่งของการตรวจตัวตนได้ตรงขอบเขต โดยไม่สับสนว่าการแสดงตัวเลขสำเร็จคือการยืนยันทั้งระบบครบแล้ว