เริ่มที่วิธี EAP ก่อน: VPN ใช้แฮชรหัสผ่านแบบใดได้
VPN ตรวจสอบความลับ ไม่ใช่แฮชของเว็บ อ่านวิธีแล้วตรวจดูว่าที่เก็บมีอะไรก่อนสัญญาว่ารหัสผ่านเดิมจะยังใช้ได้
หลายทีมมีระบบล็อกอินเว็บที่ใช้งานได้และ VPN ที่ปฏิเสธรหัสผ่านทุกตัวจากตารางเดียวกัน แอปเว็บเปรียบเทียบแฮชที่คำนวณเอง ขณะที่อุโมงค์ขอให้ไคลเอนต์พิสูจน์ว่าถือครองความลับในแบบที่เซิร์ฟเวอร์ต้องตรวจสอบได้ นี่เป็นข้อกำหนดต่างกันต่อวัสดุที่จัดเก็บ ช่องว่างระหว่างสองสิ่งนี้คือจุดที่โครงการลักษณะนี้ส่วนใหญ่ติดอยู่
อ่านวิธีก่อน แล้วจึงอ่านสคีมา
จดว่าวิธีที่เลือกต้องใช้หลักฐานอะไรก่อนจะดูสคีมาใด ๆ วิธีแบบท้าทาย-ตอบสนองต้องใช้วัสดุที่เซิร์ฟเวอร์คำนวณคำตอบที่คาดไว้ได้ ซึ่งในทางปฏิบัติหมายถึงรหัสผ่านหรือรูปแบบอนุพันธ์ที่เข้ากันได้ วิธีที่บรรจุรหัสผ่านไว้ในอุโมงค์ที่ป้องกันต้องใช้รหัสผ่านเองที่ผู้ตรวจสอบ อ่านเอกสารของวิธีเพื่อดูข้อกำหนดของผู้ตรวจสอบ ไม่ใช่การตั้งค่าไคลเอนต์ เพราะข้อกำหนดของไคลเอนต์มักเป็นส่วนที่ง่าย
แฮชเค็มที่เฟรมเวิร์กเว็บสมัยใหม่สร้างไม่ได้ให้ทั้งสองอย่าง ตรวจสอบการเปรียบเทียบหนึ่งครั้งที่เฉพาะเจาะจงและย้อนกลับไปหาความลับต้นทางไม่ได้
ท้าทาย-ตอบสนองใช้แฮชเค็มไม่ได้
MSCHAPv2 เป็นการแลกเปลี่ยนแบบท้าทาย-ตอบสนองเซิร์ฟเวอร์จึงไม่เคยได้รับรหัสผ่านและเทียบสตริงที่จัดเก็บไว้ไม่ได้ ต้องอนุมานคำตอบที่คาดไว้จากวัสดุที่มีอยู่แล้ว รูปแบบจัดเก็บที่เข้ากันได้จึงแคบมาก ค่า bcrypt หรือ Argon2 ที่มีเกลือต่อผู้ใช้เป็นแบบทางเดียวในลักษณะที่ตัดการแลกเปลี่ยนออกทั้งหมด ตารางด้านล่างเริ่มจากรูปแบบการจัดเก็บไม่ใช่ชื่อวิธี เพราะรูปแบบการจัดเก็บเป็นตัวกำหนดคำตอบ
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
เอกสาร ของปลั๊กอิน SQL สำหรับ strongSwan กำหนดสคีมาของตัวเองสำหรับการตั้งค่าและข้อมูลรับรอง และโครงกายังคงทำเครื่องหมายปลั๊กอินนั้นว่าเป็นการทดลอง ไม่มีสิ่งใดในนั้นปรับให้เข้ากับตารางผู้ใช้ของแอปพลิเคชันหรือเดาว่าโครงร่างการทำแฮชใดสร้างค่าที่จัดเก็บไว้ ตัวเลือกที่เป็นจริงจึงเป็นการย้ายไปยังที่เก็บที่เกตเวย์ใช้ได้ หรือบริการพิสูจน์ตัวตนที่อยู่หน้าและทำการแลกเปลี่ยนได้ สิ่งอื่นใดล้วนเป็นตัวเชื่อมที่มีสมมติฐานซ่อนอยู่ข้างใน
RADIUS ย้ายงาน ไม่ย้ายข้อกำหนด
การมอบ EAP ให้เซิร์ฟเวอร์ RADIUS เปลี่ยนตำแหน่งที่การตรวจสอบเกิดขึ้นและมักทำให้ร่องรอยการตรวจสอบดีขึ้น มันไม่กู้รหัสผ่านจากแฮชทางเดียวได้ บริการพิสูจน์ตัวตนจึงยังต้องใช้วัสดุที่เข้ากันได้กับวิธีที่มันสิ้นสุด ทีมต่าง ๆ รู้เรื่องนี้หลังจากสร้างเส้นทาง RADIUS แล้วเจอกำแพงเดียวกันที่อีกด้าน
ที่ใดเซิร์ฟเวอร์ RADIUS อ่านไดเรกทอรีที่มีข้อมูลรับรองที่เข้ากันได้ การออกแบบก็ทำงานและเกตเวย์ VPN ยังคงเรียบง่าย ที่ใดทำไม่ได้ คำตอบที่ซื่อตรงคือการเปลี่ยนแปลงการลงทะเบียน ไม่ใช่ตัวเชื่อมอีกตัว การจัดเตรียมและการเพิกถอนเป็นของผู้ที่เป็นเจ้าของตัวตน ตารางที่คัดลอกมาโดยไม่มีกระบวนการซิงโครไนซ์ที่รองรับจึงเป็นวงจรชีวิตข้อมูลรับรองที่สอง ไม่ใช่การลงชื่อเข้าใช้ครั้งเดียว มันคลาดเคลื่อนครั้งแรกเมื่อมีคนรีเซ็ตรหัสผ่านในที่เดียวเท่านั้น และความคลาดเคลื่อนนั้นเงียบจนกว่าบัญชีที่มีอยู่ในทั้งสองระบบจะทำงานต่างกันในแต่ละระบบ
จำกัดบัญชีที่อ่านไดเรกทอรีให้อยู่แค่การอ่านนั้น และแยกจากบัญชีที่เกตเวย์ใช้สำหรับการตั้งค่าของตัวเอง บัญชีผู้ดูแลที่ใช้ร่วมกันเปลี่ยนการออกแบบแบบอ่านอย่างเดียวเป็นรัศมีผลกระทบที่กว้างขึ้นมาก
บัญชีควรอยู่ที่ใด
เมื่อคำถามเรื่องวัสดุคลี่คลายแล้ว เหลือสองสถาปัตยกรรม เกตเวย์อาจเป็นเจ้าของที่เก็บข้อมูลรับรองขนาดเล็กที่อ่านได้เพียงตัวเอง หรือมอบหมายให้บริการพิสูจน์ตัวตนที่อยู่หน้าไดเรกทอรีองค์กร
แบบแรกคิดตามได้ง่ายกว่าและแย่กว่าสำหรับผู้ใช้ ซึ่งต้องดูแลรหัสผ่านที่สอง แบบที่สองคงตัวตนเดียวไว้และเพิ่มการพึ่งพาบริการที่ตอนนี้ต้องทำงานก่อนใครจะเชื่อมต่อได้ ไม่มีแบบใดผิด แต่ทางเลือกควรบันทึกไว้ข้างการตั้งค่าเกตเวย์ ไม่เช่นนั้นวิศวกรคนถัดไปจะถือว่าอีกแบบถูกเลือกไว้ ไม่ว่าจะเลือกแบบใด สองคำสั่งด้านล่างคือคำสั่งที่แสดงสถานะปัจจุบันก่อนคุณเปลี่ยนมัน
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsการพิสูจน์ตัวตนของบัญชีไม่ได้แก้เรื่องการอนุญาตเช่นกัน การเป็นสมาชิกกลุ่ม สถานะอุปกรณ์ และสิทธิ์เครือข่ายยังต้องมีการแมปอย่างชัดเจนหลังจากผู้ใช้พิสูจน์ตัวตนที่ต้องการแล้ว การเชื่อมต่อที่พิสูจน์ตัวตนได้สมบูรณ์แบบและไม่อนุญาตสิ่งใดเลยเป็นผลของนโยบาย ไม่ใช่ข้อบกพร่องของวิธี