รหัสความท้าทายแบบคงที่อยู่ตรงไหนในการเข้าสู่ระบบ OpenVPN

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

เริ่มจากข้อความแจ้งที่ไคลเอนต์ของคุณแสดงจริง

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

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

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

สิ่งที่เซิร์ฟเวอร์ต้องรองรับอยู่แล้ว

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

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

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

ฟิลด์ที่เข้ารหัสซึ่งอินเทอร์เฟซการจัดการส่ง

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

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

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

แบบคงที่กับแบบพลวัต: เวลาต่างกัน

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

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

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

ทดสอบทั้งความสำเร็จและความล้มเหลว ไม่ใช่แค่กล่องโต้ตอบ

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

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