ความเร็วของฟังก์ชันแฮชเป็นข้อเสียเมื่อจัดเก็บรหัสผ่านที่แฮชในฐานข้อมูลหรือไม่?

ฉันรู้ว่าข้อดีอย่างหนึ่งของฟังก์ชันแฮชคือรวดเร็วอย่างไรก็ตาม ฉันอ่านที่ไหนสักแห่ง (ไม่รู้ว่าที่ไหนกันแน่) ว่าความเร็วเป็นข้อเสียสำหรับการแฮชรหัสผ่านเมื่อจัดเก็บไว้ในฐานข้อมูล แต่ทำไมจึงเป็นเช่นนั้น ใครช่วยอธิบายให้ฉันฟังหน่อยได้ไหมว่าความรวดเร็วเป็นข้อเสียของการแฮชรหัสผ่าน และทำไมจึงเป็นเช่นนั้น ? (หากเป็นไปได้ คุณช่วยเขียนลิงก์ไปยังเว็บไซต์/เอกสารที่อธิบายสิ่งนี้ด้วยได้ไหม) นอกจากนี้ยังมีสถานการณ์อื่นๆ ที่ความรวดเร็วเป็นข้อเสียสำหรับฟังก์ชันแฮชหรือไม่ ขอบคุณล่วงหน้าสำหรับความช่วยเหลือของ.

ความเร็วสามารถเป็นข้อได้เปรียบด้วยเหตุผลหนึ่งข้อและเป็นข้อเสียสำหรับอีกเหตุผลหนึ่ง

เมื่อพูดถึงการรักษาความปลอดภัยด้วยรหัสผ่าน ความต้องการ CPU/หน่วยความจำต่ำของแฮชเข้ารหัสทำให้เกิดข้อเสีย กล่าวคือหากบันทึกหรือฐานข้อมูลถูกเปิดเผยหรือถูกแฮ็ก ผู้โจมตีมีงานเพียงเล็กน้อยที่ต้องทำเพื่อบังคับแฮชเหล่านั้นให้เป็นข้อความธรรมดา รหัสผ่าน.

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

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

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

PBKDF2 เป็นแฮชรหัสผ่านที่พบได้บ่อยมาก และแกนหลักใช้ HMAC เป็นประจำ ดังนั้น PBKDF2-HMAC-SHA256 จำนวน 40,000 รอบ อาจใช้เวลานานกว่าการทำซ้ำแฮชครั้งเดียวประมาณ 80,000 เท่า หากก่อนหน้านี้เซิร์ฟเวอร์สามารถทำแฮชซ้ำได้ 4 พันล้านครั้งต่อวินาที ตอนนี้เซิร์ฟเวอร์อาจทำ PBKDF2 ได้เพียง 50,000 แฮชก่อนที่จะทำให้ CPU อิ่มตัวอย่างสมบูรณ์ หากคุณต้องการจัดสรรทรัพยากรไม่เกิน 10% สำหรับการตรวจสอบรหัสผ่าน จะต้องมีการควบคุมปริมาณการเข้าสู่ระบบที่ 5,000 ครั้งต่อวินาที... ซึ่งอาจฟังดูมาก แต่คุณคิดว่าจะมีกี่คนที่เข้าสู่ระบบบางอย่างเช่น Gmail Lastpass หรือ Salesforce ในเวลาประมาณ 9.00 น. ของวันจันทร์?

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

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