ทำไมรหัสใช้ครั้งเดียวที่ถูกต้องจึงยังล้มเหลว هنگامเข้าสู่ระบบ VPN

คุณเปิดไคลเอนต์ VPN พิมพ์รหัสผ่าน แล้วตัวเลขหกหลักจากแอปยืนยันตัวตนกลับมาเป็นโมฆะ — สองครั้ง แล้วครั้งที่สาม ไม่มีอะไรเปลี่ยนในบัญชีตั้งแต่เมื่อวาน ดังนั้นสัญชาตญาณแรกคือลบรายการในแอปยืนยันตัวตนแล้วสแกนใหม่ — ซึ่งมักเป็นการซ่อมที่ผิด รหัสใช้ครั้งเดียวไม่ใช่รหัสผ่านที่สอง เกตเวย์ต้องขอในขั้นตอนเฉพาะ จากรายการที่ลงทะเบียนเฉพาะ ภายในหน้าต่างเวลาที่เฉพาะ และการปฏิเสธส่วนใหญ่เกิดขึ้นก่อนที่จะมีการเทียบตัวเลข หาว่าคุณอยู่ในขั้นตอนใดก่อนแตะการลงทะเบียน

ลำดับคำขอบอกว่าคุณอยู่ในโฟลว์ใด

มีสามรูปแบบที่ครอบคลุมเกือบทุกการเข้าสู่ระบบ VPN ที่มีรหัส ในรูปแบบสองขั้นตอน ไคลเอนต์ส่งรหัสผ่าน เซิร์ฟเวอร์ออกความท้าทาย แล้วไคลเอนต์ถามอีกครั้ง ในรูปแบบรวม เกตเวย์ต้องการรหัสผ่านและรหัสในการส่งครั้งเดียว — บางครั้งต่อกัน บางครั้งหลังตัวคั่นที่ผู้ดูแลเท่านั้นจัดทำเอกสาร ในรูปแบบเบราว์เซอร์ ไคลเอนต์ไม่มีช่องเลย รหัสไปอยู่ในหน้าเว็บ หรือการอนุมัติแบบพุชมาแทนที่ และไคลเอนต์เดสก์ท็อปจะรอผลลัพธ์

รูปแบบผิดดูเหมือนรหัสแย่ วางรหัสใหม่ลงในช่องที่มีไว้สำหรับรหัสผ่านเท่านั้น แล้วเซิร์ฟเวอร์จะอ่านมันเป็นส่วนหนึ่งของรหัสผ่าน ฝั่งไคลเอนต์ OpenVPN 2.4 และใหม่กว่าทำให้เห็นความแตกต่างได้ชัดขึ้น เซิร์ฟเวอร์ที่ตอบด้วย AUTH_FAILED,CRV1: คาดหวังการตอบสนองความท้าทาย โปรไฟล์จึงต้องมี static-challenge หรือไฟล์รหัสผ่านในรูปแบบ SCRV1: โปรไฟล์เก่าที่มีเพียง auth-user-pass จะตรวจสอบรหัสผ่านแล้วหยุด ซึ่งในบันทึกดูเหมือน OTP ล้มเหลวแม้จะไม่ได้ส่งรหัสใดเลย

WireGuard ควรถูกกล่าวถึงในฐานะข้อยกเว้น เพราะตรวจสอบคู่คีย์ไม่ใช่บุคคล จึงไม่มีช่องสำหรับรหัส หากผู้ให้บริการโฆษณาสิ่งนี้ ก็มีบางสิ่งนอกอุโมงค์ที่รับมัน

เซิร์ฟเวอร์ทำอะไรกับตัวเลขหกหลัก

รหัสตามเวลาปฏิบัติตาม RFC 6238 ซึ่งห่อโครงสร้างที่อิงตัวนับรุ่นเก่าจาก RFC 4226 ไว้: HMAC บนปัจจัยที่เคลื่อนที่ ตัดให้เหลือหกหลักโดยค่าเริ่มต้น สำหรับ TOTP ปัจจัยที่เคลื่อนที่คือเวลา Unix ปัจจุบันหารด้วยขั้น ปกติ 30 วินาที เว้นแต่ผู้ดูแลเปลี่ยน ตัวตรวจสอบไม่เคยเทียบตัวเลขของคุณกับค่าที่เก็บไว้ แต่คำนวณรหัสที่คาดหวังใหม่จากซีดที่ใช้ร่วมกัน และมักยอมรับขั้นข้างเคียงด้วย การไปกลับที่ช้าจึงไม่ทำให้การเข้าสู่ระบบล้มเหลว

มีสองผลที่มักถูกมองข้าม เขตเวลาของโทรศัพท์ไม่เกี่ยวข้อง เพราะซีดไม่เคยเห็นนาฬิกาท้องถิ่น มีเพียงความคลาดเคลื่อนจาก UTC จริงเท่านั้นที่สำคัญ และอุปกรณ์ที่เดินเร็วสองนาทีจะล้มเหลวทุกครั้งในขณะที่แสดงการนับถอยหลังที่ดูเรียบร้อย และรหัสเป็นแบบใช้ครั้งเดียวตามการออกแบบ ตัวตรวจสอบจำค่าตัวนับล่าสุดที่ยอมรับสำหรับซีดนั้น ตัวเลขเดิมที่ส่งซ้ำจึงถูกปฏิเสธแม้อยู่ในหน้าต่างเดียวกัน ไคลเอนต์ที่ลองใหม่หลังหมดเวลาอาจเผารหัสที่เพิ่งส่งไป

โทเค็นที่อิงตัวนับจะเลื่อนตัวนับทุกครั้งที่กด จึงหลุดจากการซิงค์หลังสร้างรหัสแต่ไม่เคยส่ง การซ่อมปกติคือหน้าต่างรีซิงค์ที่ยอมรับค่าล่วงหน้าหลายค่า หากผู้ดูแลลงทะเบียน HOTP แต่แอปของคุณแสดง TOTP ทุกค่าจะผิดในแบบที่ดูเหมือนปัญหานาฬิกา URI การจัดเตรียมหลังคิวอาร์โค้ดระบุชนิด จำนวนหลัก คาบ และแฮช

ความล้มเหลวที่ดูเหมือนรหัสผิด

รายการที่ลงทะเบียนเป็นสาเหตุที่พบบ่อยที่สุด แอปยืนยันตัวตนติดป้ายรายการตามผู้ออกและบัญชี คนที่มีสองตัวตนบน VPN เดียวจึงอาจมีสองรายการที่ป้ายต่างกันหนึ่งอักขระ รหัสใช้ได้กับซีดที่สร้างมันเท่านั้น ไม่ใช่กับสิ่งอื่นใด เปรียบเทียบป้ายชื่อบนโทรศัพท์กับชื่อผู้ใช้ที่เซิร์ฟเวอร์บันทึก ไม่ใช่กับสิ่งที่คุณจำได้ว่าพิมพ์

ที่สองคือชุดพารามิเตอร์ที่ไม่ตรงกัน ซีดที่ลงทะเบียนด้วยแปดหลัก คาบ 60 วินาที หรือ SHA-256 ให้รหัสที่ตัวตรวจสอบซึ่งคาดหกหลัก 30 วินาที และ SHA-1 ปฏิเสธ และฝั่งไคลเอนต์แยกจากรหัสผิดไม่ได้ สิ่งนี้ปรากฏหลังการย้ายระบบที่มีการเพิ่มรายการใหม่จากภาพถ่ายคิวอาร์โค้ด หรือที่มีการสร้างบันทึกโทเค็นใหม่ด้วยค่าเริ่มต้น

ที่สามไม่เกี่ยวกับรหัส เกตเวย์มักคืนความล้มเหลวการยืนยันตัวตนแบบทั่วไปหนึ่งอย่างสำหรับรหัสผ่านผิด รหัสหมดอายุ และบัญชีถูกปิด โดยเจตนา เพื่อไม่ให้ใครตรวจสอบได้ว่าปัจจัยใดล้มเหลว อ่านบันทึกของเกตเวย์หรือ RADIUS แทนแบนเนอร์ของไคลเอนต์ ความท้าทายที่ไม่เคยออก การปฏิเสธการเข้าถึงที่ไม่มีแอตทริบิวต์ OTP และการปฏิเสธตามนโยบาย ล้วนดูเหมือนกันบนหน้าจอและนำไปสู่ขั้นตอนถัดไปที่ต่างกัน

ลำดับสั้นที่ทำให้แคบลง

เริ่มจากการตรวจที่ถูกที่สุดและหยุดที่ขั้นแรกที่ไม่ผ่าน

1. รอรหัสใหม่ ส่งเพียงครั้งเดียว และสังเกตว่าความท้าทายปรากฏก่อนหรือหลังรหัสผ่านได้รับการยอมรับ
2. จับคู่ป้ายในแอปยืนยันตัวตนกับชื่อผู้ใช้ที่เซิร์ฟเวอร์เก็บไว้
3. ยืนยันว่าโปรไฟล์สามารถตอบความท้าทายได้เลย ดังกรณี CRV1 ข้างต้น
4. เปรียบเทียบนาฬิกาของอุปกรณ์กับแหล่งเวลาที่รู้จัก ความคลาดเคลื่อนเกินหลายสิบวินาทีทำให้ TOTP พังเอง
5. ถามผู้ดูแลว่าโทเค็นเป็น TOTP หรือ HOTP และลงทะเบียนจำนวนหลัก คาบ และแฮชใดไว้

มีสองกฎที่กันไม่ให้เรื่องนี้แย่ลง อย่าลองซ้ำหลายครั้ง เกตเวย์จำนวนมากนับความล้มเหลวต่อบัญชีและล็อกบัญชีหรือเริ่มหน่วงการตอบสนอง การกระหน่ำครั้งเดียวจึงเปลี่ยนข้อผิดพลาดเล็กน้อยให้เป็นตั๋วสนับสนุน และอย่าลงทะเบียนโทเค็นใหม่เพื่อวินิจฉัย เพราะจะทำให้ซีดเดิมใช้ไม่ได้ หากปัญหาจริงคือความท้าทายที่ไคลเอนต์ไม่เคยส่ง ตอนนี้คุณมีการเปลี่ยนแปลงสองอย่างให้อธิบายแทนที่จะเป็นอย่างเดียว

เก็บซีดและรหัสกู้คืนไว้นอกวงจร

ตัวเลขหกหลักและความลับเบื้องหลังไม่ใช่สิ่งที่ใช้แทนกันได้ คิวอาร์โค้ดสำหรับจัดเตรียมหรือซีด Base32 สร้างทุกรหัสในอนาคตของบัญชี จึงอยู่ในหมวดเดียวกับรหัสผ่าน ไม่ใช่ในภาพหน้าจอ ไม่ใช่ในคอมเมนต์ตั๋ว และไม่ใช่ในแชตกับใครก็ตามที่ติดต่อคุณก่อน รหัสกู้คืนเป็นกลไกแยก — ใช้ครั้งเดียว มักข้ามการขอรหัสไปเลย และการเอาไปใช้ทดสอบบัญชีหนึ่งครั้งจะตัดทางสำรองที่คุณอาจต้องใช้ในภายหลัง

รหัสไม่ได้ทำให้หน้าเข้าสู่ระบบน่าเชื่อถือ คำขอ OTP บนโดเมนที่คล้ายกันจะรวบรวมรหัสที่ใช้ได้และเล่นซ้ำภายในหน้าต่างเวลา และใบรับรองยังคงเป็นสิ่งที่บอกว่าคุณกำลังพิมพ์อยู่ที่ไหน

หากลำดับไปจบที่โปรไฟล์ที่ไม่สามารถตอบความท้าทายได้ ให้แก้โปรไฟล์และทดสอบใหม่ด้วยรหัสใหม่หนึ่งรหัส หากไปจบที่พารามิเตอร์การลงทะเบียนที่ไม่ตรงกัน ให้ผู้ดูแลอ่านบันทึกโทเค็นก่อนที่ใครจะสแกนสิ่งใด หากไปจบที่การล็อก ให้รอจนหมด แทนที่จะสลับไคลเอนต์ — อุปสรรคคือสถานะบัญชี ไม่ใช่แอป