SRP เลี่ยงการส่งรหัสผ่านระหว่างเข้าสู่ระบบ แต่ไม่ได้ทำให้ค่าตรวจสอบที่ถูกขโมยไม่มีอันตราย
Secure Remote Password หรือ SRP ช่วยให้ไคลเอนต์และเซิร์ฟเวอร์ยืนยันตัวตนด้วยรหัสผ่านได้ โดยไม่ส่งรหัสผ่านนั้นในการแลกเปลี่ยนตามปกติของโพรโทคอล จึงอาจลดการเปิดเผยรหัสผ่านต่อเซิร์ฟเวอร์ที่โดยปกติจะได้รับรหัสผ่านขณะเข้าสู่ระบบ
แต่ไม่ได้ขจัดความลับทุกชนิดที่เกี่ยวกับรหัสผ่านออกจากเซิร์ฟเวอร์ เซิร์ฟเวอร์ยังเก็บค่าตรวจสอบ และค่าตรวจสอบที่ถูกขโมยสามารถใช้เดารหัสผ่านแบบออฟไลน์ได้ ความแตกต่างนี้สำคัญอย่างยิ่งเมื่อประเมินคำกล่าวอ้างเรื่อง “การเข้าสู่ระบบแบบไม่มีความรู้”
อะไรเปลี่ยนไปเมื่อเทียบกับการเข้าสู่ระบบด้วยรหัสผ่านแบบทั่วไป?
ในการออกแบบทั่วไป ไคลเอนต์ส่งรหัสผ่านผ่านการเชื่อมต่อ TLS ที่ยืนยันความแท้จริงแล้ว เซิร์ฟเวอร์ที่ออกแบบดีจะเปรียบเทียบแฮชรหัสผ่านที่เติม salt อย่างเหมาะสม หลีกเลี่ยงการบันทึกข้อมูลรับรองลงล็อก และใช้มาตรการป้องกันการเดา TLS ปกป้องการเชื่อมต่อ ส่วนแฮชรหัสผ่านปกป้องข้อมูลรับรองที่จัดเก็บด้วยวิธีที่ต่างกัน
SRP เปลี่ยนการแลกเปลี่ยนนี้ ระหว่างลงทะเบียน ระบบสร้าง salt และข้อมูลค่าตรวจสอบ เมื่อเข้าสู่ระบบ ทั้งสองฝ่ายใช้ค่าของโพรโทคอลที่สร้างใหม่และความลับของตนเพื่อสร้างและยืนยันข้อมูลคีย์ร่วม ไคลเอนต์ใช้รหัสผ่าน ส่วนเซิร์ฟเวอร์ใช้ค่าตรวจสอบ ไคลเอนต์ที่ทำงานอย่างซื่อตรงจะไม่ส่งตัวรหัสผ่านเป็นเพย์โหลดสำหรับเข้าสู่ระบบ
ข้อกำหนด SRP ใน RFC 2945 อธิบายพื้นฐานของโพรโทคอล โปรไฟล์และการนำไปใช้ในภายหลังยังต้องตรวจทานพารามิเตอร์และการตรวจสอบข้อความที่แน่นอน การเรียกการออกแบบว่า “SRP” ไม่ได้ยืนยันว่าทุกทางเลือกในการพัฒนาถูกต้อง
| คำถาม | การเข้าสู่ระบบด้วยรหัสผ่านผ่าน TLS แบบทั่วไป | การแลกเปลี่ยน SRP ที่พัฒนาอย่างถูกต้อง |
|---|---|---|
| เซิร์ฟเวอร์แอปได้รับรหัสผ่านที่ป้อนตอนเข้าสู่ระบบหรือไม่? | โดยปกติได้รับ | ไม่ได้รับในฐานะส่วนหนึ่งของการแลกเปลี่ยนโพรโทคอล |
| เก็บข้อมูลยืนยันตัวตนที่อ่อนไหวอะไรบ้าง? | โดยทั่วไปคือแฮชรหัสผ่านที่เติม salt | salt และค่าตรวจสอบที่อนุมานจากรหัสผ่าน |
| ฐานข้อมูลที่ถูกขโมยใช้เดาแบบออฟไลน์ได้หรือไม่? | ได้ ขึ้นกับข้อมูลที่เก็บ | ได้ ข้อมูลค่าตรวจสอบ SRP ที่ถูกขโมยใช้เดาได้ |
| ป้องกันโปรแกรมบันทึกการกดแป้นพิมพ์หรือไม่? | ไม่ | ไม่ |
| เข้ารหัสประวัติข้อความโดยอัตโนมัติหรือไม่? | ไม่ | ไม่ |
เหตุใดค่าตรวจสอบที่ถูกขโมยจึงยังสำคัญ
RFC 5054 หัวข้อ 3.3 กล่าวถึงค่าตรวจสอบที่ถูกขโมยอย่างชัดเจน โดยอธิบายว่าค่าตรวจสอบอาจทำให้ผู้โจมตีปลอมเป็นเซิร์ฟเวอร์และโจมตีด้วยพจนานุกรมเพื่อกู้รหัสผ่านได้
ความแตกต่างสำคัญคือค่าตรวจสอบไม่ใช่เพียงโทเค็นเข้าสู่ระบบของไคลเอนต์ที่ใช้ซ้ำได้ แต่ไม่ได้หมายความว่ามันไม่มีอันตราย ผู้โจมตีสามารถทดสอบรหัสผ่านที่คาดเดากับข้อมูลที่ขโมยมา แทนการแก้ปัญหาลอการิทึมไม่ต่อเนื่องสำหรับทุกความลับที่เป็นไปได้ รหัสผ่านที่อ่อนแอหรือใช้ซ้ำยังคงเป็นความเสี่ยงร้ายแรง
การจำกัดอัตราออนไลน์อาจทำให้ความพยายามโจมตีบริการที่ทำงานอยู่ช้าลง แต่ไม่ควบคุมการคำนวณที่ทำกับฐานข้อมูลที่ถูกขโมย การปกป้องฐานข้อมูล การประมวลผลรหัสผ่านอย่างรอบคอบ และรหัสผ่านที่แข็งแกร่งไม่ซ้ำกันจึงยังสำคัญ
สิ่งที่ SRP ไม่ได้ป้องกัน
อุปกรณ์ปลายทางที่ถูกเจาะ: มัลแวร์อาจจับรหัสผ่านก่อนเริ่มโพรโทคอล หรือขโมยเซสชันที่ยืนยันตัวตนแล้วในภายหลัง
หน้าเข้าสู่ระบบที่เป็นอันตราย: หากหน้าที่ขอรหัสผ่านมีเจตนาร้ายอยู่แล้ว มันสามารถส่งข้อความที่ป้อนไปยังที่อื่นได้ เว็บแอปยังต้องมีเส้นทางการส่งมอบที่เชื่อถือได้
เส้นทางกู้คืนทั้งหมด: ขั้นตอนทางอีเมล SMS หรือฝ่ายสนับสนุนที่ให้สิทธิ์เข้าถึงบัญชีมีข้อกำหนดของตนเอง วิธีเข้าสู่ระบบปกติที่แข็งแกร่งที่สุดอาจถูกบั่นทอนด้วยช่องทางสำรองที่อ่อนแอกว่า
การโจมตีเครือข่ายเชิงรุกทุกชนิด: พารามิเตอร์โพรโทคอล การตรวจสอบอินพุต การยืนยันซึ่งกันและกัน และการเชื่อมต่อที่ยืนยันความแท้จริงซึ่งครอบอยู่ล้วนสำคัญ อย่าแทนที่การป้องกัน TLS ที่กำหนดไว้สำหรับระบบด้วยคำขวัญว่า “รหัสผ่านไม่เคยถูกส่ง”
เมทาดาทาหรือการเข้ารหัสแชต: การยืนยันตัวตนตอบว่าควรอนุญาตให้เซสชันเข้ามาหรือไม่ ไม่ได้กำหนดว่ามีบันทึกการสนทนาใดอยู่ หรือใครถือคีย์ถอดรหัสข้อความ
Livara แยกการเข้าสู่ระบบออกจากการกู้คืนตัวตนอย่างไร
ภาพรวมความปลอดภัย ของ Livara อธิบายการยืนยันตัวตน SRP แยกจากโพรโทคอลส่งข้อความ LVR1 และยังอธิบายข้อมูลสำรองตัวตนที่เข้ารหัสในเวอร์ชัน 7 ซึ่งปกป้องด้วยคีย์กู้คืนแบบสุ่มขนาด 256 บิตที่แยกต่างหาก
ข้อมูลสำรองถูกเข้ารหัสและผนึกก่อนอัปโหลด และกู้คืนตัวตนทางการเข้ารหัส ไม่ใช่ประวัติแชต การรู้เพียงรหัสผ่านบัญชีไม่ทำให้กู้คีย์เข้ารหัสเหล่านั้นได้ ในทางกลับกัน ข้อความที่ว่าฝ่ายสนับสนุนไม่สามารถสร้างความลับด้านการเข้ารหัสขึ้นใหม่ ไม่ได้ยืนยันว่าไม่มีการจัดการบัญชีหรือขั้นตอนเปลี่ยนรหัสผ่านใด ๆ ได้เลย
แบบจำลองภัยคุกคาม ยังรวมการถูกเจาะของอุปกรณ์และเมทาดาทาการสื่อสารที่มองเห็นได้ไว้ในขอบเขตด้วย ไม่ควรใช้ SRP มาเปลี่ยนคำเรียกทั้งบริการว่า “ไม่มีความรู้” เกี่ยวกับกิจกรรมของผู้ใช้ทุกด้าน
รายการตรวจสอบเพื่อประเมินในทางปฏิบัติ
สำหรับผู้ใช้ ให้เลือกรหัสผ่านที่แข็งแกร่งและไม่ซ้ำ ปกป้องอุปกรณ์ เก็บข้อมูลกู้คืนในที่แยกต่างหากอย่างเหมาะสม และเข้าใจวิธีเพิกถอนเซสชัน อย่าพิมพ์ความลับลงในเว็บไซต์ที่ไม่เชื่อถือเพียงเพราะอ้างว่าใช้ SRP
สำหรับผู้ตรวจสอบทางเทคนิค ให้ขอโปรไฟล์โพรโทคอลที่แน่นอน กระบวนการแปลงรหัสผ่านเป็นค่าตรวจสอบ การตรวจสอบอินพุต การจัดการความล้มเหลว ขั้นตอนลงทะเบียน และการออกแบบรีเซ็ต ตรวจทานไคลเอนต์กับเซิร์ฟเวอร์ร่วมกัน รวมการทดสอบค่าสาธารณะที่ไม่ถูกต้อง การโจมตีแบบส่งซ้ำ และเซสชันที่ถูกขัดจังหวะ แทนการพึ่งเพียงการทดสอบเข้าสู่ระบบสำเร็จ
SRP เป็นเครื่องมือที่มีประโยชน์ในการจำกัดการเปิดเผยรหัสผ่านระหว่างยืนยันตัวตน คุณค่าของมันชัดเจนขึ้นเมื่ออธิบายประโยชน์จริงควบคู่กับความเสี่ยงจากค่าตรวจสอบที่ถูกขโมย อุปกรณ์ปลายทางที่ถูกเจาะ และการกู้คืน แทนที่จะนำเสนอว่าเป็นจุดสิ้นสุดของปัญหาความปลอดภัยรหัสผ่าน
