การแฮชรหัสผ่านปกป้องคุณจากอะไรกันแน่

สรุปสั้น ๆ

การแฮชรหัสผ่านช่วยปกป้องผู้ใช้เมื่อฐานข้อมูลรหัสผ่านของคุณถูกขโมย

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

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

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

หากคุณเข้าใจขอบเขตนี้ คุณจะตัดสินใจได้ดีขึ้นเกี่ยวกับอัลกอริทึม ค่า work factor การรีเซ็ต การบันทึกล็อก และการตอบสนองต่อเหตุการณ์

แฮชรหัสผ่านคืออะไร

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

เมื่อผู้ใช้สร้างบัญชี ระบบควรทำประมาณนี้:

1. รับรหัสผ่านผ่าน HTTPS.
2. สร้าง salt แบบสุ่มและไม่ซ้ำกัน
3. ส่งรหัสผ่านและ salt ผ่านฟังก์ชันแฮชรหัสผ่าน เช่น Argon2id, bcrypt, scrypt หรือ PBKDF2.
4. จัดเก็บชื่ออัลกอริทึม พารามิเตอร์ salt และแฮชที่ได้
5. ทิ้งรหัสผ่านต้นฉบับ

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

ส่วนสำคัญคือ: แอปพลิเคชันไม่จำเป็นต้องรู้รหัสผ่านต้นฉบับ เพียงต้องตรวจสอบว่ารหัสผ่านที่ส่งเข้ามาสร้างผลลัพธ์ที่คาดไว้ได้หรือไม่

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

การแฮชปกป้องคุณจากอะไร

1. การเปิดเผยรหัสผ่านทันทีหลังฐานข้อมูลรั่วไหล

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

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

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

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

นั่นไม่สมบูรณ์แบบ มันยังคงเป็นการรั่วไหล แต่เป็นรูปแบบความล้มเหลวที่ดีกว่าอย่างมาก

2. การโจมตีแบบปริมาณมากต่อฐานผู้ใช้ทั้งหมดของคุณ

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

salt ไม่ใช่ความลับ มันถูกจัดเก็บไว้ข้างแฮช หน้าที่ของมันคือความไม่ซ้ำกัน

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

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

3. การเดาแบบออฟไลน์ที่รวดเร็ว

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

นี่คือจุดที่การเลือกอัลกอริทึมมีความสำคัญ

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

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

Argon2id ได้รับการแนะนำอย่างกว้างขวางสำหรับระบบใหม่ เพราะสามารถกำหนดค่าให้ต้องใช้ทั้งเวลา CPU และหน่วยความจำ ซึ่งทำให้การถอดรหัสด้วย GPU ขนาดใหญ่มีต้นทุนสูงขึ้น bcrypt ยังคงพบได้ทั่วไปและยอมรับได้เมื่อกำหนดค่าอย่างดี แม้จะมีข้อจำกัด เช่น การจัดการความยาวรหัสผ่าน PBKDF2 ยังคงใช้ในบางสภาพแวดล้อมที่ขับเคลื่อนด้วยข้อกำหนดการปฏิบัติตามกฎ โดยเฉพาะเมื่อจำเป็นต้องใช้คอมโพเนนต์ที่ผ่านการตรวจสอบตาม FIPS

หลักการนั้นเรียบง่าย: ทำให้การล็อกอินที่ถูกต้องเร็วพอรับได้ ขณะเดียวกันทำให้การเดาหลายพันล้านครั้งมีราคาแพง

การแฮชไม่ได้ปกป้องคุณจากอะไร

1. ฟิชชิง

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

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

การแฮชรหัสผ่านเป็นแนวป้องกันสำรองสำหรับความลับที่จัดเก็บไว้ ไม่ใช่การป้องกันผู้ใช้ที่ถูกหลอกให้มอบความลับเหล่านั้น

2. การยัดข้อมูลรับรอง

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

แฮชรหัสผ่านของคุณอาจยอดเยี่ยม แต่การยัดข้อมูลรับรองก็ยังได้ผลหากผู้ใช้ใช้รหัสผ่านซ้ำ

นี่คือการโจมตีแบบออนไลน์ต่อฟอร์มล็อกอินของคุณ ไม่ใช่การโจมตีแบบออฟไลน์ต่อฐานข้อมูลของคุณ คุณต้องมี rate limiting การตรวจจับความผิดปกติ การตรวจรหัสผ่านที่เคยรั่ว MFA และนโยบาย lockout ที่สมเหตุสมผลซึ่งไม่สร้างโอกาสให้ denial-of-service ได้ง่าย

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

3. รหัสผ่านที่ถูกจับไว้ในล็อกหรือ analytics

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

ความล้มเหลวที่พบบ่อย ได้แก่:

• บันทึก request bodies แบบเต็มในความพยายามล็อกอินที่ล้มเหลว
• ส่งรหัสผ่านไปยังเครื่องมือตรวจสอบข้อผิดพลาด
• จับข้อมูลฟิลด์รหัสผ่านในผลิตภัณฑ์ session replay
• รวมข้อมูลรับรองไว้ใน URLs ระหว่างโฟลว์รีเซ็ตหรือย้ายระบบที่ออกแบบมาไม่ดี
• จัดเก็บรหัสผ่านชั่วคราวแบบข้อความล้วนระหว่างการนำเข้า

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

มองฟิลด์รหัสผ่านเป็นข้อมูลเป็นพิษ ปิดบังข้อมูลก่อนบันทึกล็อก แยกออกจาก analytics อย่าใส่ไว้ใน URLs จำกัดผู้ที่เข้าถึง production traces ได้

4. ความปลอดภัยของเซสชันที่แย่

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

การแฮชรหัสผ่านไม่ได้ป้องกัน cross-site scripting คุกกี้ที่ไม่ปลอดภัย session fixation การสร้างโทเคนที่อ่อนแอ หรืออายุเซสชันที่ยาวเกินไป

คุกกี้เซสชันสมควรถูกทบทวนโดยเฉพาะ: HttpOnly, Secure, SameSite ที่เหมาะสม เซสชันความเสี่ยงสูงที่มีอายุสั้น และการทำให้ใช้ไม่ได้ฝั่งเซิร์ฟเวอร์เมื่อเปลี่ยนรหัสผ่าน ภูมิทัศน์ด้านความเป็นส่วนตัวและเบราว์เซอร์ที่กว้างขึ้นก็เปลี่ยนแปลงต่อเนื่องเช่นกัน ตามที่กล่าวไว้ใน สิ่งที่เปลี่ยนไปสำหรับคุกกี้ในปี 2026

5. การรีเซ็ตรหัสผ่านและการกู้คืนบัญชีที่อ่อนแอ

การยึดบัญชีจำนวนมากไม่ได้เริ่มจากรหัสผ่าน แต่เริ่มจากโฟลว์รีเซ็ต

หาก reset tokens คาดเดาได้ มีอายุยาว รั่วผ่าน referrer headers หรือถูกส่งไปยังบัญชีอีเมลที่ถูกยึด การแฮชรหัสผ่านก็ช่วยคุณไม่ได้

ใช้ reset tokens ที่มี entropy สูง หน้าต่างหมดอายุสั้น ใช้ครั้งเดียว และการแจ้งเตือนผู้ใช้ที่ชัดเจน เนื่องจากอีเมลมักเป็นช่องทางกู้คืน การยืนยันตัวตนของโดเมนขั้นพื้นฐานก็สำคัญเช่นกัน หากทีมของคุณมองระเบียน DNS เป็นพิธีกรรมลึกลับ ให้เริ่มจาก ทัวร์ MX, SPF, DKIM และ DMARC สำหรับนักพัฒนา

การเลือกอัลกอริทึม: ตอนนี้ควรใช้อะไร

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

ลำดับความเหมาะสมสมัยใหม่ที่สมเหตุสมผลมีหน้าตาแบบนี้:

1. Argon2id สำหรับระบบใหม่เมื่อมีให้ใช้
2. bcrypt เมื่อ Argon2id ไม่เหมาะในทางปฏิบัติและการรองรับ bcrypt มีความพร้อม
3. scrypt เมื่อการกำหนดค่าแบบใช้หน่วยความจำมากได้รับการรองรับอย่างดี
4. PBKDF2 เมื่อถูกบังคับด้วยข้อจำกัดของแพลตฟอร์มหรือการปฏิบัติตามกฎ

หลีกเลี่ยง SHA-256, SHA-512, MD5 แบบธรรมดา หรือการผสมที่คิดขึ้นเอง เช่น sha256(password + salt) แฮชที่รวดเร็วไม่ใช่ฟังก์ชันจัดเก็บรหัสผ่าน โครงสร้างทำเองที่ดูฉลาดมักแย่กว่ามาตรฐานที่เรียบง่ายและน่าเบื่อ

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

Cost factors ไม่ใช่ตั้งครั้งเดียวแล้วลืม

การแฮชรหัสผ่านมีพารามิเตอร์ Argon2id มีหน่วยความจำ จำนวนรอบ และ parallelism bcrypt มี cost factor PBKDF2 มีจำนวนรอบการทำซ้ำ

ค่เหล่านี้ควรถูกเลือกตามสภาพแวดล้อม production ของคุณ ต่ำเกินไป ผู้โจมตีก็เดาได้ถูกต้นทุน สูงเกินไป ระบบล็อกอินของคุณก็ช้าหรือเปราะบางต่อ denial-of-service

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

อย่าคัดลอก cost factor จากบล็อกโพสต์เมื่อห้าปีก่อน ฮาร์ดแวร์เปลี่ยน ไลบรารีเปลี่ยน ทราฟฟิกของคุณเปลี่ยน

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

Peppers: มีประโยชน์ แต่ไม่ใช่สิ่งทดแทน

pepper คือค่าลับที่เพิ่มเข้าไปในกระบวนการแฮชรหัสผ่านและจัดเก็บแยกจากฐานข้อมูล มักอยู่ใน secrets manager หรือ hardware security module

ต่างจาก salt, pepper ต้องยังคงเป็นความลับ

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

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

เช็กลิสต์เชิงปฏิบัติการ

หากคุณรับผิดชอบระบบจริง เช็กลิสต์เชิงปฏิบัตินั้นสั้น:

• จัดเก็บรหัสผ่านด้วยอัลกอริทึมแฮชรหัสผ่านมาตรฐานเท่านั้น
• ใช้ salt แบบสุ่มที่ไม่ซ้ำกันต่อรหัสผ่านแต่ละรายการ
• เลือก Argon2id สำหรับงานสร้างใหม่
• ปรับพารามิเตอร์ต้นทุนบนฮาร์ดแวร์ที่ใกล้เคียง production
• จัดเก็บอัลกอริทึมและพารามิเตอร์ไว้กับแฮชแต่ละรายการ
• Rehash เมื่อมีการล็อกอิน หากพารามิเตอร์ล้าสมัย
• อย่าบันทึกรหัสผ่านในล็อกหรือส่งไปยังเครื่องมือ analytics
• ใช้ TLS ทุกที่ที่มีการส่งข้อมูลรับรอง
• เพิ่ม MFA หรือ passkeys เมื่อความเสี่ยงสมเหตุสมผล
• ปกป้องโฟลว์รีเซ็ตอย่างจริงจังเท่ากับโฟลว์ล็อกอิน
• มีแผนรับมือเหตุการณ์สำหรับการบังคับรีเซ็ตและการแจ้งผู้ใช้

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

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: ดูว่าอินพุตเดียวกันแมปไปยังอัลกอริทึมต่าง ๆ อย่างไรด้วย Hash Generator ซึ่งทำให้เห็นความแตกต่างระหว่างแฮชที่รวดเร็วกับแฮชระดับรหัสผ่านได้อย่างเป็นรูปธรรม

<!-- tool-cta:end -->

โมเดลความคิดที่ตรงไปตรงมา

วิธีคิดที่ดีที่สุดเกี่ยวกับการแฮชรหัสผ่านคือแบบนี้:

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

มันปกป้องตัวตรวจสอบที่จัดเก็บไว้

ฟังดูแคบ แต่สำคัญอย่างยิ่ง ฐานข้อมูลรั่วได้ ข้อมูลสำรองรั่วได้ ระบบ staging ถูกคัดลอกได้ ผู้ขายได้รับสิทธิ์เข้าถึงที่ไม่ควรมี ไฟล์ export เก่า ๆ นอนอยู่ใน object storage นานกว่าที่ใครจำได้

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

นั่นคือสิ่งที่การแฮชรหัสผ่านปกป้องคุณจากจริง ๆ