SRP: โพรโทคอลรหัสผ่านระยะไกลที่ปลอดภัย

โพรโทคอลรหัสผ่านระยะไกลแบบปลอดภัย (SRP) พัฒนาโดย Tom Wu ที่มหาวิทยาลัย Stanford และเผยแพร่เป็น RFC 2945 ในปี 2000 ต่อมามีการกำหนดรุ่นปรับปรุงที่เรียกว่า SRP-6a SRP ช่วยให้ยืนยันตัวตนร่วมกันได้โดยอาศัยรหัสผ่านร่วมกัน โดยไม่ส่งรหัสผ่านจริงแม้แต่ในรูปแบบเข้ารหัส

ระหว่างการลงทะเบียน SRP ไคลเอนต์จะคำนวณค่าตรวจสอบรหัสผ่าน v = g^x mod N โดยที่ x = H(salt || password) และ N คือจำนวนเฉพาะปลอดภัยขนาดใหญ่ เซิร์ฟเวอร์จะจัดเก็บเฉพาะค่าเกลือและค่าตรวจสอบ v แม้ฐานข้อมูลของเซิร์ฟเวอร์จะถูกเจาะ ค่าตรวจสอบที่จัดเก็บไว้ก็ไม่เปิดเผยรหัสผ่านโดยตรง

ระหว่างการเข้าสู่ระบบด้วย SRP ทั้งไคลเอนต์และเซิร์ฟเวอร์จะทำการแลกเปลี่ยนลักษณะเดียวกับ Diffie-Hellman ซึ่งสร้างคีย์เซสชันร่วมกัน การคำนวณของแต่ละฝ่ายจะใช้ค่าที่ได้จากรหัสผ่านด้วย ดังนั้นคีย์เซสชันที่ได้จึงคำนวณได้อย่างถูกต้องเฉพาะโดยผู้ที่รู้รหัสผ่านและผู้ที่มีค่าตรวจสอบตามลำดับ

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

ค่าตรวจสอบคำนวณเป็น v = g^x mod N โดยที่ x = H(salt || password), g เป็นตัวกำเนิด และ N เป็นจำนวนเฉพาะปลอดภัยขนาด 2048 บิตขึ้นไป ปัญหาลอการิทึมไม่ต่อเนื่องทำให้การกู้คืน x จาก v ไม่สามารถทำได้ในทางคำนวณอย่างมีประสิทธิภาพ การตรวจสอบรหัสผ่านจะทำได้โดยทำการแลกเปลี่ยน SRP ทั้งหมดให้สำเร็จเท่านั้น

SRP-6a แก้ไขจุดอ่อนของการออกแบบ SRP-3 และ SRP-6 รุ่นเดิมด้วยการเพิ่มพารามิเตอร์ตัวคูณ k = H(N, g) และปรับลำดับการคำนวณของไคลเอนต์กับเซิร์ฟเวอร์ การเปลี่ยนแปลงเหล่านี้ป้องกันการโจมตีแบบเดาค่าที่ใช้ประโยชน์ได้สองทางบางประเภท และทำให้ส่วนร่วมของเซิร์ฟเวอร์ถูกผูกไว้ตั้งแต่ช่วงต้นของโพรโทคอล

SRP ถูกนำไปใช้งานจริงอย่างแพร่หลาย บริษัทแอปเปิลใช้ SRP ในการซิงโครไนซ์พวงกุญแจ iCloud เพื่อให้อุปกรณ์ต่าง ๆ เรียกดูข้อมูลพวงกุญแจได้โดยไม่เปิดเผยรหัสผ่านบัญชีแก่เซิร์ฟเวอร์ของแอปเปิล 1Password ใช้ SRP ในรูปแบบการยืนยันตัวตนเพื่อป้องกันการเปิดเผยข้อมูลรับรองฝั่งเซิร์ฟเวอร์

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

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

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

แม้ SRP จะเป็นนวัตกรรมสำคัญ แต่ทางเลือกสมัยใหม่อย่าง OPAQUE ให้หลักประกันด้านความปลอดภัยที่แข็งแกร่งกว่า (มีความต้านทานต่อการคำนวณล่วงหน้า) และ FIDO2/กุญแจผ่านก็กำจัดรหัสผ่านโดยสิ้นเชิง สำหรับระบบใหม่ ควรเลือก OPAQUE หรือ FIDO2 แต่ SRP ยังคงเป็นตัวเลือกที่เหมาะสมสำหรับระบบที่ต้องการการยืนยันตัวตนร่วมกันด้วยรหัสผ่านโดยไม่เสี่ยงต่อฟิชชิง

ใน SRP เซิร์ฟเวอร์จัดเก็บอะไรแทนรหัสผ่านของผู้ใช้

SRP จัดเก็บค่าตรวจสอบรหัสผ่าน (ไม่ใช่รหัสผ่าน) สร้างคีย์เซสชันร่วมกันผ่านการแลกเปลี่ยนลักษณะเดียวกับ DH และให้การยืนยันตัวตนร่วมกันที่ทนทานต่อฟิชชิง SRP-6a ปรับปรุงรุ่นเดิมให้ทนทานต่อการโจมตีแบบเดาค่า พวงกุญแจ iCloud ของแอปเปิลและ 1Password ใช้ SRP ในระบบที่ใช้งานจริง ส่วน OPAQUE และ FIDO2 เป็นรุ่นต่อยอดสมัยใหม่สำหรับระบบใหม่