เกลือที่ไม่สุ่มสำหรับแฮชรหัสผ่าน

อัปเดต: เมื่อเร็ว ๆ นี้ฉันได้เรียนรู้จากคำถามนี้ว่าในการสนทนาทั้งหมดด้านล่างฉัน (และฉันแน่ใจว่าคนอื่น ๆ ก็ทำเช่นกัน) ค่อนข้างสับสน: สิ่งที่ฉันเรียกตารางสายรุ้งนั้นแท้จริงแล้วเรียกว่าตารางแฮช ตารางสายรุ้งเป็นสิ่งมีชีวิตที่ซับซ้อนกว่าและเป็นรูปแบบหนึ่งของ Hellman Hash Chains แม้ว่าฉันจะเชื่อว่าคำตอบนั้นยังคงเหมือนเดิม (เนื่องจากไม่ได้มีการเข้ารหัสลับ) การสนทนาบางส่วนอาจจะเบี้ยวเล็กน้อย
คำถาม: " อะไรคือตารางรุ้งและวิธีการที่พวกเขาใช้? "

โดยปกติฉันมักจะแนะนำให้ใช้ค่าสุ่มที่มีการเข้ารหัสที่แข็งแกร่งเป็นเกลือเสมอเพื่อใช้กับฟังก์ชันแฮช (เช่นรหัสผ่าน) เช่นเพื่อป้องกันการโจมตีของ Rainbow Table

แต่จริง ๆ แล้วมันจำเป็นสำหรับการสุ่มเกลือหรือไม่? ค่าที่ไม่ซ้ำกัน (ไม่ซ้ำกันต่อผู้ใช้เช่น userId) จะเพียงพอหรือไม่ในเรื่องนี้ ในความเป็นจริงมันจะป้องกันไม่ให้ใช้ Rainbow Table เดียวเพื่อถอดรหัสรหัสผ่านทั้งหมด (หรือส่วนใหญ่) ในระบบ ...
แต่การขาดเอนโทรปีทำให้ความแข็งแกร่งในการเข้ารหัสของฟังก์ชันแฮชลดลงหรือไม่?

หมายเหตุฉันไม่ได้ถามว่าทำไมต้องใช้เกลือวิธีการป้องกัน (ไม่จำเป็นต้องเป็น) การใช้แฮชคงที่เดียว (ไม่ต้อง) หรือฟังก์ชันแฮชประเภทใดที่จะใช้
เพียงแค่ว่าเกลือต้องการเอนโทรปีหรือไม่

ขอบคุณทุกคนสำหรับคำตอบจนถึงตอนนี้ แต่ฉันอยากจะเน้นในส่วนที่ฉันไม่ค่อยคุ้นเคย (นิดหน่อย) ผลกระทบส่วนใหญ่สำหรับการเข้ารหัส - ฉันจะขอบคุณมากที่สุดถ้าใครมีข้อมูลบางอย่างจาก PoV ทางคณิตศาสตร์การเข้ารหัสลับ
นอกจากนี้หากมีเวกเตอร์เพิ่มเติมที่ไม่ได้รับการพิจารณาก็เป็นข้อมูลที่ดีเช่นกัน (ดูที่ @Dave Sherohman ชี้ในหลายระบบ)
นอกเหนือจากนั้นหากคุณมีทฤษฎีแนวคิดหรือแนวทางปฏิบัติที่ดีที่สุดโปรดสำรองข้อมูลนี้ด้วยการพิสูจน์สถานการณ์การโจมตีหรือหลักฐานเชิงประจักษ์ หรือแม้กระทั่งการพิจารณาที่ถูกต้องสำหรับการแลกเปลี่ยนที่ยอมรับได้ ... ฉันคุ้นเคยกับแนวทางปฏิบัติที่ดีที่สุด (ตัวพิมพ์ใหญ่ B ทุน P) ในหัวข้อนี้ฉันต้องการพิสูจน์ว่าสิ่งนี้ให้คุณค่าอย่างไร

แก้ไข: คำตอบที่ดีจริงๆที่นี่ แต่ฉันคิดว่าอย่างที่ @Dave พูดมันลงมาที่ Rainbow Tables สำหรับชื่อผู้ใช้ทั่วไป ... และอาจมีชื่อสามัญน้อยกว่าด้วย อย่างไรก็ตามจะเกิดอะไรขึ้นหากชื่อผู้ใช้ของฉันไม่ซ้ำกันทั่วโลก? ไม่จำเป็นต้องซ้ำกันสำหรับระบบของฉัน แต่สำหรับผู้ใช้แต่ละคนเช่นที่อยู่อีเมล
จะไม่มีแรงจูงใจในการสร้าง RT สำหรับผู้ใช้รายเดียว (ตามที่ @Dave เน้นย้ำว่าเกลือจะไม่ถูกเก็บเป็นความลับ) และยังคงป้องกันไม่ให้เกิดการรวมกลุ่ม ปัญหาเดียวคือฉันอาจมีอีเมลและรหัสผ่านเดียวกันในไซต์อื่น - แต่เกลือจะไม่สามารถป้องกันได้อยู่ดี
ดังนั้นจึงกลับลงมาที่การเข้ารหัส - เอนโทรปีจำเป็นหรือไม่? (ความคิดในปัจจุบันของฉันไม่จำเป็นจากมุมมองของการเข้ารหัส แต่มาจากเหตุผลในทางปฏิบัติอื่น ๆ )

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

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

อันตรายที่ยิ่งใหญ่กว่าจากแนวคิดนี้ก็คือชื่อผู้ใช้มักจะถูกนำกลับมาใช้ - ไซต์ใด ๆ ที่คุณต้องการเข้าชมจะมีบัญชีผู้ใช้ชื่อ "Dave" เป็นต้นและ "ผู้ดูแลระบบ" หรือ "root" ก็เป็นเรื่องธรรมดามากขึ้นซึ่งจะทำให้ การสร้างตารางสายรุ้งที่กำหนดเป้าหมายผู้ใช้ด้วยชื่อสามัญเหล่านั้นง่ายและมีประสิทธิภาพมากขึ้น

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

แก้ไขเพื่อเพิ่ม: ผู้คนจำนวนมากกำลังพูดถึงเอนโทรปีและว่าเอนโทรปีในเกลือมีความสำคัญหรือไม่ มันเป็น แต่ไม่ใช่ด้วยเหตุผลส่วนใหญ่ของความคิดเห็นในเรื่องนี้ดูเหมือนจะคิด

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

เหตุผลที่เอนโทรปีมีความสำคัญคือการหลีกเลี่ยงการรวมกลุ่มของค่าเกลือ หากเกลือขึ้นอยู่กับชื่อผู้ใช้และคุณทราบว่าระบบส่วนใหญ่จะมีบัญชีชื่อ "root" หรือ "admin" คุณสามารถสร้างตารางสายรุ้งสำหรับเกลือทั้งสองนี้และจะทำให้ระบบส่วนใหญ่แตก ในทางกลับกันถ้าใช้เกลือ 16 บิตแบบสุ่มและค่าสุ่มมีการแจกแจงแบบสม่ำเสมอคุณต้องมีตารางรุ้งสำหรับเกลือที่เป็นไปได้ทั้งหมด 2 ^ 16

ไม่ได้เกี่ยวกับการป้องกันไม่ให้ผู้โจมตีรู้ว่าเกลือของแต่ละบัญชีคืออะไร แต่เป็นการไม่ให้เป้าหมายที่ใหญ่และอ้วนเป็นเกลือเม็ดเดียวที่จะใช้กับเป้าหมายที่เป็นไปได้ในสัดส่วนที่มาก

การใช้เกลือที่มีเอนโทรปีสูงเป็นสิ่งจำเป็นอย่างยิ่งในการจัดเก็บรหัสผ่านอย่างปลอดภัย

ใช้ชื่อผู้ใช้ของฉัน 'gs' และเพิ่มลงในรหัสผ่านของฉัน 'MyPassword' จะให้ gsMyPassword สิ่งนี้หักได้ง่ายโดยใช้ตารางรุ้งเพราะถ้าชื่อผู้ใช้มีเอนโทรปีไม่เพียงพออาจเป็นไปได้ว่าค่านี้ถูกเก็บไว้ในตารางรุ้งแล้วโดยเฉพาะอย่างยิ่งถ้าชื่อผู้ใช้สั้น

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

พวกเขาเคยมีเกลือ 12 บิต 12 บิตคือชุดค่าผสมที่แตกต่างกัน 4096 ที่ไม่ปลอดภัยเพียงพอเนื่องจากว่าข้อมูลมากสามารถเก็บได้ง่ายในปัจจุบัน เช่นเดียวกับชื่อผู้ใช้ที่ใช้บ่อยที่สุด 4096 มีแนวโน้มว่าผู้ใช้ของคุณไม่กี่คนจะเลือกชื่อผู้ใช้ที่เป็นของชื่อผู้ใช้ที่พบบ่อยที่สุด

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

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

แฮช ("www.yourpage.com /" + ชื่อผู้ใช้ + "/" + รหัสผ่าน)

สิ่งนี้ควรแก้ปัญหาได้ ฉันไม่ใช่ผู้เชี่ยวชาญด้านการเข้ารหัสลับ แต่ฉันสงสัยว่าการที่เราไม่ใช้เอนโทรปีสูงจะทำให้แฮชอ่อนแอลง

ฉันชอบใช้ทั้งสอง: เกลือที่มีเอนโทรปีสูงแบบสุ่มต่อเรกคอร์ดบวกกับ ID เฉพาะของเร็กคอร์ด

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

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

หากรู้จักเกลือหรือเดาได้ง่ายแสดงว่าคุณไม่ได้เพิ่มความยากในการโจมตีพจนานุกรม อาจเป็นไปได้ที่จะสร้างตารางสายรุ้งที่ปรับเปลี่ยนแล้วโดยคำนึงถึงเกลือ "คงที่"

การใช้เกลือที่เป็นเอกลักษณ์ช่วยเพิ่มความยากในการโจมตีพจนานุกรมจำนวนมาก

การมีค่าเกลือที่แข็งแกร่งในการเข้ารหัสลับเฉพาะจะเหมาะอย่างยิ่ง

ฉันจะบอกว่าตราบใดที่เกลือแตกต่างกันสำหรับแต่ละรหัสผ่านคุณอาจจะโอเค จุดของเกลือคือคุณไม่สามารถใช้ตารางรุ้งมาตรฐานเพื่อแก้รหัสผ่านทั้งหมดในฐานข้อมูล ดังนั้นหากคุณใส่เกลือที่แตกต่างกันกับทุกรหัสผ่าน (แม้ว่าจะไม่ใช่แบบสุ่มก็ตาม) โดยพื้นฐานแล้วผู้โจมตีจะต้องคำนวณตารางสายรุ้งใหม่สำหรับรหัสผ่านแต่ละรหัสเนื่องจากแต่ละรหัสผ่านใช้เกลือที่แตกต่างกัน

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

ความแรงของฟังก์ชันแฮชไม่ได้ถูกกำหนดโดยอินพุต!

การใช้เกลือที่ผู้โจมตีรู้จักทำให้การสร้างตารางสายรุ้ง (โดยเฉพาะอย่างยิ่งสำหรับชื่อผู้ใช้ที่เข้ารหัสยากเช่นรูท ) น่าสนใจยิ่งขึ้น แต่ก็ไม่ได้ทำให้แฮชลดลงกัญชาการใช้เกลือที่ผู้โจมตีไม่รู้จักจะทำให้ระบบโจมตีได้ยากขึ้น

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

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

อย่างไรก็ตามฉันจะบอกว่าอัลกอริทึมการย่อยที่คุณเลือกมีความสำคัญมากกว่า การใช้ SHA-512 จะพิสูจน์ได้ว่าสร้างความเจ็บปวดให้กับคนที่สร้างตารางสายรุ้งมากกว่า MD5

เกลือควรมีเอนโทรปีให้มากที่สุดเพื่อให้แน่ใจว่าควรแฮชค่าอินพุตที่กำหนดหลาย ๆ ครั้งค่าแฮชที่ได้จะใกล้เคียงที่สุดเท่าที่จะทำได้ซึ่งแตกต่างกันเสมอ

การใช้ค่าเกลือที่เปลี่ยนแปลงตลอดเวลาโดยมีเอนโทรปีมากที่สุดในเกลือจะช่วยให้มั่นใจได้ว่าโอกาสในการแฮช (เช่นรหัสผ่าน + เกลือ) จะสร้างค่าแฮชที่แตกต่างกันอย่างสิ้นเชิง

ยิ่งมีเอนโทรปีในเกลือน้อยเท่าไหร่โอกาสที่คุณจะสร้างค่าเกลือเท่ากันก็จะยิ่งมีโอกาสมากขึ้นในการสร้างค่าแฮชที่เท่ากัน

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

เอนโทรปีคือจุดของค่าเกลือ

หากมี "คณิตศาสตร์" ที่เรียบง่ายและทำซ้ำได้อยู่เบื้องหลังเกลือก็เท่ากับว่าไม่มีเกลืออยู่ แค่เพิ่มมูลค่าเวลาก็น่าจะดี