ฉันควรแฮชรหัสผ่านก่อนส่งไปยังฝั่งเซิร์ฟเวอร์หรือไม่?

ฉันสังเกตเห็นว่าไซต์ส่วนใหญ่ส่งรหัสผ่านเป็นข้อความธรรมดาผ่าน HTTPS ไปยังเซิร์ฟเวอร์ มีข้อดีหรือไม่ถ้าฉันส่งแฮชของรหัสผ่านไปยังเซิร์ฟเวอร์แทน จะปลอดภัยกว่าไหม

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

OP ไม่เคยกล่าวถึงการส่งรหัสผ่านอย่างชัดเจนผ่าน HTTP - เฉพาะ HTTPS แต่ดูเหมือนว่าหลายคนจะตอบคำถามเกี่ยวกับการส่งรหัสผ่านผ่าน HTTP ด้วยเหตุผลบางประการ ที่กล่าวว่า:

ฉันเชื่อว่ารหัสผ่านไม่ควรถูกเก็บไว้ (ปล่อยให้ส่งคนเดียว) เป็นข้อความธรรมดา นั่นหมายถึงไม่ได้เก็บไว้ในดิสก์หรือแม้แต่ในหน่วยความจำ

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

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

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

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

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

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

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

TL; DR:

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

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

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

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

การไม่ใช้ https ถือเป็นการละเมิด OWASP Top 10: A9-Insufficient Transport Layer Protection

แก้ไข: หากในการใช้งานของคุณคุณคำนวณ a sha256(client_salt+plain_text_password)แล้วคำนวณแฮชอื่นในฝั่งเซิร์ฟเวอร์sha256(server_salt+client_hash)นี่ไม่ใช่ช่องโหว่ร้ายแรง อย่างไรก็ตามยังคงมีความอ่อนไหวต่อการดักฟังและเล่นซ้ำคำขอ ดังนั้นนี่จึงยังถือเป็นการละเมิด WASP A9 อย่างชัดเจน อย่างไรก็ตามนี่ยังคงใช้การแยกข้อความเป็นชั้นความปลอดภัย

สิ่งที่ใกล้เคียงที่ฉันได้เห็นการเปลี่ยนฝั่งไคลเอ็นต์สำหรับ https เป็นDiffie-Hellman ในการแลกเปลี่ยนที่สำคัญในจาวาสคริปต์ อย่างไรก็ตามสิ่งนี้จะป้องกันการโจมตี MITM ที่ใช้งานอยู่และด้วยเหตุนี้จนกว่าทางเทคนิคจะละเมิด OWASP A9 ผู้เขียนโค้ดยอมรับว่านี่ไม่ใช่การแทนที่ HTTPS โดยสมบูรณ์ แต่ดีกว่าไม่มีอะไรและดีไปกว่าระบบแฮชฝั่งไคลเอ็นต์

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

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

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

เพื่อแก้ปัญหานี้แน่นอนคุณสามารถแฮชที่เซิร์ฟเวอร์ได้รับและเรียกมันว่าวัน

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

ใช้ HTTP Digest - รักษารหัสผ่านแม้กระทั่งผ่าน http (แต่การใช้งานที่ดีที่สุดคือ http Digest ผ่าน https)

วิกิพีเดีย:

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

ลิงค์: http://en.wikipedia.org/wiki/Digest_access_authentication

หากคุณต้องการดูการใช้งาน "ในชีวิตจริง" คุณสามารถดูที่ phpMyID ซึ่งเป็นผู้ให้บริการ php openid ที่ใช้การตรวจสอบการแยกย่อย http http://siege.org/phpmyid.php

.. หรือคุณสามารถเริ่มจากตัวอย่าง php auth ที่http://php.net/manual/en/features.http-auth.php

http แยกย่อย rfc: http://www.faqs.org/rfcs/rfc2617

จากการทดสอบของฉันเบราว์เซอร์สมัยใหม่ทั้งหมดรองรับ ...

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

อย่างไรก็ตามการทำให้รหัสผ่านฝั่งไคลเอ็นต์สับสนขั้นพื้นฐาน (ไม่ใช่แฮช) ที่ส่งผ่าน HTTPS จะมีค่าบางอย่าง ถ้าฉันจำไม่ผิดเทคนิคนี้ถูกใช้โดยธนาคารบางแห่ง จุดประสงค์ของเทคนิคนี้ไม่ใช่เพื่อป้องกันรหัสผ่านจากการดมกลิ่นบนสายไฟ แต่เป็นการหยุดไม่ให้ใช้รหัสผ่านกับเครื่องมือสอดแนมที่โง่เขลาและปลั๊กอินของเบราว์เซอร์ที่เพียงแค่คว้าทุกคำขอ HTTPS GET / POST ที่พวกเขาเห็น ฉันเห็นไฟล์บันทึกที่บันทึกจากเว็บไซต์ที่เป็นอันตรายซึ่งมีขนาด 400MB ของธุรกรรม GET / POST แบบสุ่มที่จับได้จากเซสชันของผู้ใช้ คุณสามารถจินตนาการได้ว่าเว็บไซต์ที่ใช้เพียง HTTPS จะแสดงรหัสผ่านแบบข้อความชัดเจนในบันทึก แต่เว็บไซต์ที่มีการทำให้สับสนขั้นพื้นฐาน (ROT13) เช่นกันจะแสดงรหัสผ่านที่ไม่ได้ใช้งานทันที

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

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

ทำทั้งสองอย่าง

ทำทั้งสองอย่างเพราะ:

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

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

จริงอยู่ที่พวกเขาสามารถสร้างความเสียหายอื่น ๆ ได้มากมายหากพวกเขามีอิสระในการอ่านสิ่งที่พวกเขาต้องการจากฐานข้อมูลของคุณ

ฉันแค่อยากจะเน้นย้ำตรงนี้ว่าหากคุณตัดสินใจที่จะแฮชคีย์ก่อนออกเดินทางจากลูกค้าของคุณนั่นยังไม่เพียงพอการแฮชแบ็กเอนด์คือ imo สำคัญกว่ามากและนี่คือเหตุผลว่าทำไม: หากมีคนดักฟังการเข้าชมจากคุณ จากนั้นลูกค้าจะเห็นเนื้อหาของpasswordฟิลด์ ไม่ว่าจะเป็นแฮชหรือข้อความธรรมดาก็ไม่สำคัญ - พวกเขาสามารถคัดลอกคำต่อคำเพื่อแอบอ้างเป็นลูกค้าที่ได้รับอนุญาต (เว้นแต่คุณจะทำตามขั้นตอนที่ @ user3299591 ระบุไว้และฉันขอแนะนำให้คุณทำ) ในทางกลับกันการแฮชคอลัมน์ DB เป็นสิ่งจำเป็นและไม่ใช่เรื่องยากที่จะนำไปใช้

SSL / TLS ไม่ได้แทนที่ nonce ใช่หรือไม่ ฉันไม่เห็นคุณค่าเพิ่มเติมของสิ่งนี้เนื่องจาก SSL / TLS ยังป้องกันการโจมตีซ้ำ

อ้างอิง https://en.wikipedia.org/wiki/Cryptographic_nonce

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

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

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

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

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

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

แนวคิดที่ควรทราบ:

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