สมมติว่าฉันต้องการตั้งค่ากลยุทธ์การตรวจสอบชื่อผู้ใช้และรหัสผ่านแบบคลาสสิกบนเซิร์ฟเวอร์ การสื่อสารทั้งหมดเข้ารหัสผ่าน TLS แต่โดยหลักการแล้ว ฉันยังไม่ต้องการให้เซิร์ฟเวอร์สามารถอ่านรหัสผ่านในรูปแบบข้อความล้วนได้ แม้จะเป็นการชั่วคราวก็ตาม ในตอนท้ายไคลเอ็นต์สามารถส่งรหัสผ่านที่แฮชและใส่เกลือด้วยคีย์บางตัว (เพื่อความง่ายสมมติว่าเป็นชื่อผู้ใช้) ขอเรียกสิ่งนี้ว่า ได้มา รหัสผ่าน. จากนั้นเซิร์ฟเวอร์จะแฮชและเกลือรหัสผ่านที่ได้รับโดยใช้อัลกอริทึมเช่น Bcrypt หรือ PBKDF2 และจัดเก็บไว้สำหรับคำขอในอนาคต
จนถึงขณะนี้ยังไม่มีสิ่งใดแปลกใหม่และมีการอภิปรายมากมายเกี่ยวกับหัวข้อนี้ แต่สิ่งที่ฉันไม่พบในการสนทนาเหล่านี้คือวิธีการตรวจสอบฝั่งเซิร์ฟเวอร์ของ ความแข็งแกร่ง ของ ข้อความธรรมดา รหัสผ่านในคำถาม? การตรวจสอบความถูกต้องของฝั่งไคลเอ็นต์สามารถข้ามได้ หรือแอปพลิเคชันไคลเอ็นต์อาจมีจุดบกพร่องที่ตรวจสอบความถูกต้องของความแรงได้ไม่เพียงพอ ดังนั้น การตรวจสอบความถูกต้องของความแรงจึงควรดำเนินการบนเซิร์ฟเวอร์ แต่ในเวลาเดียวกัน ฉันไม่ต้องการให้เซิร์ฟเวอร์เข้าถึงรหัสผ่านข้อความล้วน
ดังนั้นคำถามของฉันคือ ข้อกำหนด 2 ข้อนี้ไม่เกิดร่วมกัน หรือมีวิธีใดบ้างที่จะบรรลุข้อกำหนดทั้งสองข้อ สามารถตรวจสอบความรัดกุมตามรหัสผ่านที่ได้รับได้หรือไม่ อย่างน้อยที่สุด เป็นไปได้หรือไม่ที่จะตรวจสอบความยาวของรหัสผ่านข้อความล้วนโดยใช้รหัสผ่านที่ได้รับมาเพื่อป้องกันการลงทะเบียนด้วยรหัสผ่านว่างเปล่า หรือในฐานะเจ้าของโปรเจ็กต์ ฉันแค่ต้องยอมรับว่าผู้ใช้บางรายสามารถข้ามการตรวจสอบฝั่งไคลเอ็นต์และไม่รับผิดชอบใดๆ หากบัญชีของพวกเขาถูกบุกรุกอันเป็นผลมาจากการข้ามการตรวจสอบระดับความแข็งแกร่งฝั่งไคลเอ็นต์
ฉันทราบดีว่าอาจมีการใช้กลยุทธ์แบบผสมผสาน โดยรหัสผ่านจะถูกส่งจากไคลเอ็นต์ในรูปแบบข้อความล้วนระหว่างการลงทะเบียน/รีเซ็ตรหัสผ่านเท่านั้น และในรูปแบบแฮชแบบเค็มสำหรับคำขอที่ตามมา นี่เป็นการปรับปรุงที่เหนือกว่าการส่งรหัสผ่านแบบข้อความล้วนตลอดเวลา แต่ก็ยังไม่เป็นไปตามข้อกำหนดที่จะไม่เปิดเผยรหัสผ่านแบบข้อความธรรมดาไปยังเซิร์ฟเวอร์
คุณไม่สามารถตรวจสอบความปลอดภัยของรหัสผ่านใดๆ ที่ถูกแฮชแล้วเมื่อส่งถึงคุณตามความเป็นจริง ฟังก์ชันแฮชเป็นฟังก์ชันทางเดียวโดยการออกแบบ หมายความว่าคุณไม่ควรจะย้อนกลับแฮชและรับข้อมูลที่มีความหมายเกี่ยวกับอินพุตได้
อย่างไรก็ตาม คุณสามารถตรวจสอบได้โดยง่ายว่ารหัสผ่านไม่ได้อยู่ในรายการสั้นๆ ของรหัสผ่านทั่วไปที่ไม่รัดกุม เช่น สตริงว่าง "", "abc", "123", "password" เป็นต้น คุณทำได้ง่ายๆ เพียง ทำซ้ำขั้นตอนการแฮชฝั่งไคลเอนต์กับฝั่งเซิร์ฟเวอร์อินพุตเหล่านี้ และตรวจสอบความเท่าเทียมกัน ความยาวของรายการรหัสผ่านที่ไม่รัดกุมดังกล่าวจะถูกจำกัดโดยข้อจำกัดด้านประสิทธิภาพ เนื่องจากแฮชที่ส่งโดยไคลเอ็นต์เป็นแบบเค็ม เซิร์ฟเวอร์จะต้องสร้างรายการนี้ใหม่สำหรับการลงทะเบียนและการเปลี่ยนรหัสผ่านแต่ละครั้ง
ดังนั้น การตรวจสอบความถูกต้องของรหัสผ่านจำนวนมากจะต้องดำเนินการฝั่งไคลเอ็นต์ โดยมีเงื่อนไขว่ารหัสผ่านจะถูกส่งเป็นค่าแฮชเท่านั้น
ความคิดของคุณเกี่ยวกับรูปแบบการลงทะเบียนแบบผสม ซึ่งรหัสผ่านจะถูกส่งเป็นข้อความธรรมดาไปยังเซิร์ฟเวอร์เพื่อตรวจสอบอย่างรวดเร็วเท่านั้น ไม่เหมาะสม ดังที่คุณได้กล่าวไปแล้ว ในการเริ่มต้น คุณจะไม่ได้รับประโยชน์มากนักจากการให้ลูกค้าส่งรหัสผ่านแบบข้อความธรรมดา แทนที่จะเป็นแฮชธรรมดาของรหัสผ่านเดียวกัน การตรวจสอบสติส่วนใหญ่ที่ได้รับประโยชน์จากการมีรหัสผ่านแบบข้อความล้วนสามารถทำได้โดยง่ายจากฝั่งไคลเอ็นต์ การทดสอบฝั่งเซิร์ฟเวอร์จำนวนมากควรทำเป็นการค้นหาในฐานข้อมูลแฮชของรหัสผ่านที่ไม่รัดกุมทั่วไป (ตารางสายรุ้ง)
ที่กล่าวว่าไม่พบแฮชในตารางฐานข้อมูลนั้นไม่ได้รับประกันว่ารหัสผ่านนั้นแข็งแกร่งเพียงพอรหัสผ่านแบบยาวที่เป็นการเชื่อมคำแบบสุ่มสามหรือสี่คำจากพจนานุกรม อาจพบได้ง่ายหากคุณเข้าถึงรหัสผ่านแบบข้อความล้วน แต่อาจไม่ใช่รหัสผ่านแม้แต่ในตารางสายรุ้งขนาดใหญ่พอสมควร
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
