การใช้ Salt ในระบบรักษาความปลอดภัยคืออะไร? คำอธิบายเกี่ยวกับการเข้ารหัสรหัสผ่าน (Password Hashing)

ในเดือนมิถุนายน 2012 ผู้โจมตีได้ปล่อยข้อมูลบัญชี LinkedIn จำนวน 117 ล้านรายการลงในฟอรัมของรัสเซีย ข้อมูลดังกล่าวเป็นรหัสแฮช SHA-1 ที่ไม่มีการใช้เกลือ (unsalt) SHA-1 มีความเร็วสูง หากไม่มีเกลือมาช่วยแยกข้อมูลรหัสผ่านที่เหมือนกัน รหัสแฮชเดียวกันจะปรากฏอยู่ติดกันหลายพันครั้ง ภายในเวลาประมาณเจ็ดสิบสองชั่วโมง นักวิจัยด้านความปลอดภัยสามารถถอดรหัสไฟล์ได้ประมาณเก้าสิบเปอร์เซ็นต์ เมื่อการรั่วไหลของข้อมูลนี้กลับมาปรากฏอีกครั้งในเดือนพฤษภาคม 2016 ในรูปแบบของชุดข้อมูลขนาด 167 ล้านรายการ ข้อมูลประจำตัวเหล่านั้นถูกนำไปใช้ในการโจมตีแบบ Credential Stuffing มานานหลายปี

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

ความล้มเหลวในการจัดเก็บรหัสผ่านในปัจจุบันส่วนใหญ่ยังคงมีสาเหตุมาจากต้นตอเดียวกัน นั่นคือ มีคนตัดสินใจว่า "การใช้ SHA-256 ก็เพียงพอแล้ว" บทความนี้จะอธิบายว่าการเพิ่มเกลือ (salting) คืออะไร ทำงานอย่างไรในทางปฏิบัติ ป้องกันอะไรได้บ้างและป้องกันอะไรไม่ได้บ้าง และ OWASP แนะนำให้ใช้ค่าเริ่มต้นใดสำหรับปี 2026

การใช้คำว่า "salting" ในการรักษาความปลอดภัยและการเข้ารหัสรหัสผ่านคืออะไร

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

การแฮชเพียงอย่างเดียวเป็นการสื่อสารทางเดียว การนำรหัสผ่านไปผ่าน SHA-256 หรือ Argon2id จะให้ค่าที่มีความยาวคงที่ซึ่งไม่มีอัลกอริทึมใดสามารถย้อนกลับได้ ข้อเสียคือ "ไม่มีอัลกอริทึมใด" นั้นไม่รวมทางลัดราคาถูกอย่างหนึ่ง นั่นคือการค้นหาค่าแฮชในพจนานุกรมที่คำนวณไว้ล่วงหน้า การเพิ่มเกลือ (Salt) จะปิดทางลัดนั้น การเพิ่มเกลือในกระบวนการแฮชจะสร้างค่าแฮชที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละคน แม้ว่าข้อความรหัสผ่านพื้นฐานจะเหมือนกันทุกคำก็ตาม รหัสผ่านทั่วไปเช่น "password" และ "qwerty" จะไม่เกิดการชนกันในฐานข้อมูลอีกต่อไป การเพิ่มเกลือช่วยให้มั่นใจได้ว่าการรั่วไหลของข้อมูลเพียงแถวเดียวจะไม่บอกอะไรผู้โจมตีเกี่ยวกับผู้ใช้รายอื่นเลย

มีกฎสามข้อที่แยกเกลือ (salt) ที่ใช้งานได้ออกจากเกลือที่ไร้ประโยชน์ กฎข้อแรก: รหัสผ่านทุกรหัสจะต้องมีเกลือแบบสุ่มของตัวเอง ซึ่งสร้างขึ้นใหม่ทุกครั้งที่ผู้ใช้ลงทะเบียนหรือรีเซ็ต รหัสผ่านที่มีเกลือที่นำกลับมาใช้ซ้ำในหลายบัญชีแทบจะไม่ดีไปกว่ารหัสผ่านที่ไม่มีเกลือ – การโจมตีแบบกลุ่มทำงานในลักษณะเดียวกัน กฎข้อที่สอง: เกลืออาจเป็นสาธารณะ การรู้เกลือเพียงอย่างเดียวไม่ได้ทำให้ผู้โจมตีมีทางลัดใดๆ ในการโจมตีฟังก์ชันแฮช ดังนั้นเกลือจึงอยู่ในฐานข้อมูลถัดจากฟังก์ชันแฮช และการจัดวางเช่นนั้นก็เหมาะสมและได้รับการสนับสนุนด้วยซ้ำ กฎข้อที่สาม: ค่าเกลือมาจากตัวสร้างเลขสุ่มเทียมที่มีความปลอดภัยทางด้านการเข้ารหัส Linux เปิดเผยตัวสร้างเลขสุ่มเทียมผ่าน `getrandom(2)` Node เรียกมันว่า `crypto.randomBytes` ไลบรารีมาตรฐานของ Python ห่อหุ้มมันไว้ใน `secrets.token_bytes` `Math.random()` ที่ไม่มีความปลอดภัยทางด้านการเข้ารหัสไม่เหมาะสม แม้ว่าจะปรากฏในโค้ดที่ตรวจสอบแล้วบ่อยกว่าที่ควรจะเป็นก็ตาม

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

การเพิ่มเกลือให้กับรหัสผ่านทำงานอย่างไร

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

ขั้นตอนแรกจะทำงานในระหว่างการลงทะเบียน แอปพลิเคชันจะขอข้อมูลสุ่มจำนวน 16 ถึง 32 ไบต์จาก CSPRNG ซึ่งก็คือค่า "salt" คำแนะนำของ OWASP ปี 2025 กำหนดให้ 16 ไบต์ (128 บิต) เป็นค่าต่ำสุด ส่วน auth0 และผู้จำหน่ายโปรแกรมจัดการรหัสผ่านหลายรายแนะนำให้ใช้ถึง 32 ไบต์ มาตรฐาน SP 800-63B-4 ของ NIST กำหนดค่าต่ำสุดไว้ที่ 4 ไบต์ แต่เตือนว่าปัญหาการชนกันของข้อมูลเนื่องจากวันเกิดของผู้ใช้จะเริ่มปรากฏขึ้นเมื่อมีผู้ใช้ประมาณ 65,000 คน ซึ่งเป็นเหตุผลว่าทำไมจึงไม่มีใครใช้ค่า 4 ไบต์จริงๆ

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

ขั้นตอนที่สามคือการนำข้อมูลที่รวมกันแล้วไปผ่านอัลกอริทึมการแฮชรหัสผ่าน ซึ่งในตำราการเข้ารหัสเรียกว่าฟังก์ชันการสร้างคีย์ หรือ KDF นี่คือขั้นตอนที่ทีมส่วนใหญ่มักจะพลาดพลั้ง โดยมักจะเลือกใช้อัลกอริทึมแฮชทั่วไปและคิดว่างานเสร็จแล้ว SHA-256 แบบธรรมดานั้นไม่เหมาะสมสำหรับการจัดเก็บรหัสผ่านเพียงอย่างเดียว GPU สำหรับผู้บริโภคในปี 2026 สามารถประมวลผลแฮช SHA-256 ได้มากกว่าหนึ่งแสนล้านครั้งต่อวินาที ดังนั้นแม้จะมีเกลือ (salt) ต้นทุนต่อการเดาในการเข้ารหัสก็ยังคงน้อยมาก การใช้เกลือจะกำจัดช่องโหว่การโจมตีแบบ Rainbow Table แต่ไม่ได้ทำให้การถอดรหัสรหัสผ่านด้วยวิธี Brute Force ช้าลง เครื่องมือที่เหมาะสมในที่นี้คือฟังก์ชันที่ทำงานช้าและใช้หน่วยความจำสูงโดยเจตนา: Argon2id เป็นค่าเริ่มต้นที่ OWASP แนะนำ โดยมี scrypt และ bcrypt ที่ยอมรับได้ และ PBKDF2 ที่อนุญาตให้ใช้เมื่อต้องปฏิบัติตามข้อกำหนด FIPS-140 โดยมีจำนวนการวนซ้ำสูงมาก

ขั้นตอนที่สี่จะจัดเก็บทั้งค่าแฮชและค่าเกลือ (salt) ไลบรารีสมัยใหม่จัดการรูปแบบการจัดเก็บนี้ ดังนั้นคุณจึงไม่ต้องจัดการค่าเกลือที่จัดเก็บไว้ด้วยตนเอง เอาต์พุตของ bcrypt จะมีลักษณะเช่น `$2b$12$9f4c8a7b...kQR8YZpL9` — สตริงเดียวนี้ประกอบด้วยตัวระบุอัลกอริทึม ปัจจัยต้นทุน ค่าเกลือ และค่าแฮช Argon2id ใช้รูปแบบสตริง PHC ที่คล้ายกันคือ `$argon2id$v=19$m=19456,t=2,p=1$$` คุณเขียนสตริงนั้นลงในคอลัมน์ฐานข้อมูลแล้วปล่อยให้ระบบทำงานเอง ไลบรารีได้ทำทุกอย่างที่จำเป็นเพื่อจัดเก็บรหัสผ่านอย่างปลอดภัยแล้ว — สร้างข้อมูลสุ่มสำหรับค่าเกลือ ประมวลผลรหัสผ่านผ่านอัลกอริทึมแฮชที่ช้า และรวมผลลัพธ์ไว้สำหรับการเรียกใช้

การล็อกอินใช้กระบวนการเดียวกันแต่กลับกัน แอปพลิเคชันจะค้นหาค่า salt และ hash ที่จัดเก็บไว้ของผู้ใช้ จากนั้นนำรหัสผ่านที่ส่งมาไปประมวลผลด้วยอัลกอริทึมเดียวกันโดยใช้ค่า salt เดียวกัน และเปรียบเทียบผลลัพธ์กับ hash ที่จัดเก็บไว้โดยใช้การเปรียบเทียบแบบใช้เวลาคงที่ การเปรียบเทียบแบบใช้เวลาคงที่นั้นสำคัญมาก เพราะการใช้ `==` แบบง่ายๆ จะเปิดเผยข้อมูลเกี่ยวกับจำนวนไบต์ที่ตรงกัน ซึ่งทำให้เกิดช่องโหว่ในการโจมตีแบบจับเวลาได้ ควรใช้ `hmac.compare_digest`, `crypto.timingSafeEqual` หรือฟังก์ชันที่เทียบเท่าในเฟรมเวิร์กของคุณ

เหตุใดการใส่เกลือจึงสำคัญ: ปัญหาโต๊ะสีรุ้ง

ตารางเรนโบว์ (Rainbow table) คือการโจมตีเฉพาะที่การเติมเกลือ (salting) ถูกคิดค้นขึ้นมาเพื่อต่อต้าน ลองนึกภาพตารางค้นหาที่คำนวณไว้ล่วงหน้าซึ่งจับคู่รหัสผ่านที่เป็นไปได้ทั้งหมด ไม่ว่าจะเป็นคำในพจนานุกรม รูปแบบทั่วไป หรือรายการจากรายชื่อที่รั่วไหล ไปยังค่าแฮช SHA-256 ของมัน ตารางเหล่านี้มีอยู่จริง มีการขายกันในฟอรัมเกี่ยวกับการแฮ็ก และมีขนาดใหญ่ถึงระดับเทราไบต์ เมื่อผู้โจมตีมีฐานข้อมูลที่ดัมพ์ค่าแฮชที่ไม่ได้เติมเกลือ การค้นหาค่าแฮชในตารางเรนโบว์จึงเป็นเพียงการสืบค้นฐานข้อมูล ไม่ใช่การแฮ็กข้อมูล เหตุการณ์ LinkedIn ในปี 2012 ก็เป็นเช่นนั้น: ค่าแฮช SHA-1 ที่ไม่ได้เติมเกลือจำนวน 117 ล้านค่า ถูกนำไปทดสอบกับตารางเรนโบว์ และสามารถถอดรหัสได้ถึง 90 เปอร์เซ็นต์ภายในเวลาประมาณสามวัน

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

นั่นคือหน้าที่ทั้งหมดของการใช้เกลือ (salt) มันมีขอบเขตจำกัดโดยเจตนา การใช้เกลือไม่ได้ช่วยชะลอการโจมตีแบบเดาสุ่ม (brute-force) ที่มุ่งเป้าไปที่ผู้ใช้รายใดรายหนึ่งโดยเฉพาะ การใช้เกลือไม่ได้หยุดยั้งการโจมตีแบบยัดเยียดข้อมูลประจำตัว (credential-stuffing) จากการรั่วไหลก่อนหน้านี้ การใช้เกลือไม่ได้ช่วยอะไรหากรหัสผ่านคือ "123456" — ผู้โจมตีจะลองใช้พจนานุกรมที่เห็นได้ชัด และเกลือจะถูกคำนวณใหม่ทุกครั้งที่เดา แต่จะไม่เปลี่ยนแปลงต้นทุนต่อการเดาอย่างมีนัยสำคัญ

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

การแฮช การเข้ารหัส และการใส่เกลือ

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

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

กรณีการรั่วไหลของข้อมูลของ Adobe ในปี 2013 เป็นตัวอย่างที่ควรระวัง Adobe จัดเก็บข้อมูลผู้ใช้ 153 ล้านรายการโดยการเข้ารหัสรหัสผ่านด้วย 3DES ในโหมด ECB ภายใต้คีย์เดียวที่ใช้ทั่วทั้งเว็บไซต์ การเลือกใช้วิธีนี้เป็นความผิดพลาดถึงสามประการ การเข้ารหัสไม่ใช่รูปแบบพื้นฐานที่เหมาะสมสำหรับการจัดเก็บรหัสผ่าน โหมด ECB ทำให้ข้อมูลอินพุตที่เหมือนกันกลายเป็นข้อมูลเอาต์พุตที่เหมือนกัน การใช้คีย์เดียวซ้ำทั่วทั้งฐานข้อมูลหมายความว่าการถอดรหัสคีย์เพียงครั้งเดียวจะถอดรหัสข้อมูลทั้งหมด 153 ล้านรายการ Schneier เรียกเหตุการณ์นี้ว่าเป็นการรั่วไหลของรหัสผ่านที่เลวร้ายที่สุดครั้งหนึ่งในประวัติศาสตร์ วิธีแก้ไขในทุกระดับคือการเปลี่ยนไปใช้การแฮชแบบช้าและมีการเพิ่มเกลือ (salted, slow hashing)

เกลือกับพริกไทย: การป้องกันสองชั้น

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

รูปแบบภัยคุกคามคือการโจรกรรมฐานข้อมูลเพียงอย่างเดียว หากผู้โจมตีขโมยฐานข้อมูลไปได้ — ผ่านการโจมตีแบบ SQL injection, การสำรองข้อมูลที่ตั้งค่าไม่ถูกต้อง หรือการรั่วไหลของข้อมูลสำรอง — พวกเขามีเพียง salt และ hash แต่ไม่มี pepper หากไม่มี pepper พวกเขาไม่สามารถเริ่มการโจมตีแบบ brute-force ได้เลย เพราะทุกๆ การเดาที่พวกเขาสร้าง hash นั้นขาดตัวแก้ไขความลับส่วนกลาง (global secret modifier)

โดยทั่วไปแล้ว การใช้งานจะเรียกใช้ `argon2id(salt + password + pepper)` หรือที่ละเอียดกว่านั้นคือ คำนวณ `HMAC(pepper, password + salt)` ก่อน แล้วจึงป้อนผลลัพธ์ลงใน Argon2id OWASP แนะนำให้ใช้ pepper สำหรับระบบที่มีมูลค่าสูง แต่ก็ยอมรับถึงข้อเสียคือ การหมุนเวียน pepper นั้นยุ่งยากในทางปฏิบัติ การหมุนเวียนหมายถึงการสร้างแฮชรหัสผ่านของผู้ใช้ทุกคนใหม่ทุกครั้งที่เข้าสู่ระบบครั้งถัดไป และหาก pepper สูญหายโดยไม่มีการสำรองข้อมูล บัญชีทั้งหมดก็จะตรวจสอบไม่ได้ แอปพลิเคชันสำหรับผู้บริโภคส่วนใหญ่จึงไม่ใช้ pepper แต่สำหรับธนาคาร หน่วยงานรัฐบาล และงานด้านการดูแลสุขภาพ มักจะใช้ pepper

การเข้ารหัสรหัสผ่านแบบทันสมัยในปี 2026

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

Argon2id ใช้หน่วยความจำสูง หมายความว่าการเดาแต่ละครั้งไม่เพียงแต่ใช้รอบการทำงานของ CPU เท่านั้น แต่ยังใช้ RAM จำนวนหนึ่งด้วย มาตรฐาน OWASP ขั้นต่ำที่ 19 MiB ต่อแฮช หมายความว่าผู้โจมตีที่สร้าง ASIC แบบกำหนดเองจะต้องสร้างหน่วยความจำความเร็วสูงจำนวนมากด้วย และหน่วยความจำเป็นส่วนที่แพงที่สุดของระบบใดๆ ก็ตาม เวอร์ชัน "id" ผสมผสาน Argon2i (ทนทานต่อการโจมตีแบบ side-channel) และ Argon2d (ทนทานต่อ GPU) โดยใช้ Argon2i ในครึ่งแรกและ Argon2d ในครึ่งหลัง

scrypt มีมาก่อน Argon2id และทำงานบนหลักการเดียวกันคือใช้หน่วยความจำสูง bcrypt นั้นเก่ากว่า เรียบง่ายกว่า และมีข้อจำกัดด้านขนาดอินพุตที่ 72 ไบต์ ซึ่งบางครั้งอาจทำให้แอปพลิเคชันที่ใช้รหัสผ่านยาวๆ เกิดปัญหาได้ — หากต้องการอินพุตที่ยาวกว่านั้น ให้ใช้ SHA-256 ในการแฮชก่อน แล้วเข้ารหัสแบบ base64 PBKDF2 เป็นตัวเลือกที่ช้าแต่เป็นไปตามมาตรฐาน FIPS; OWASP ได้เพิ่มจำนวนการวนซ้ำเป็น 600,000 สำหรับ SHA-256 ในปี 2023 จากเดิม 310,000

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

ข้อผิดพลาดทั่วไปในการใส่เกลือที่มักพบเห็นได้ในการตรวจสอบจริง

รายงานการละเมิดข้อมูลในโลกแห่งความเป็นจริงมักชี้ให้เห็นข้อผิดพลาดเดิมๆ เพียงไม่กี่อย่าง

การใช้ salt ตัวเดียวกันซ้ำสำหรับผู้ใช้ทุกคนเป็นการทำลายกลไกทั้งหมด — ปัญหาตารางสีรุ้งกลับมาอีกครั้ง เพียงแต่มีขั้นตอนเพิ่มขึ้นอีกหนึ่งขั้นตอน การใช้ชื่อผู้ใช้เป็น salt นั้นแย่กว่า เพราะชื่อผู้ใช้จะซ้ำกันในระบบต่างๆ และสามารถคำนวณตารางสีรุ้งล่วงหน้าสำหรับชื่อผู้ใช้ยอดนิยมได้ ความยาวของ salt ที่ต่ำกว่าสิบหกไบต์จะเริ่มทำให้เกิดการชนกันในระดับฐานผู้ใช้ขนาดใหญ่ การสร้าง salt ด้วยฟังก์ชันสุ่มที่ไม่ใช่การเข้ารหัส — `Math.random()`, `time(0)` mod something ซึ่งเป็น RNG เริ่มต้นของภาษา — จะสร้างค่าที่คาดเดาได้ ซึ่งทำให้การใช้ salt หมดประโยชน์ไป

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

ปัญหาใหญ่ที่สุดที่พบในการตรวจสอบปี 2026 คือการใช้แฮช SHA-256 แบบธรรมดา บวกกับเกลือ (salt) และการส่งค่า (shipping) เกลือนี้ช่วยป้องกันตารางเรนโบว์ (rainbow table) แต่ไม่ได้แก้ปัญหาสำหรับฟาร์ม GPU ที่ทำการเดา 10,000 ล้านครั้งต่อวินาทีกับบัญชีเดียว วิธีแก้ไม่ใช่การเพิ่มเกลือตัวที่สอง แต่เป็นการเปลี่ยนไปใช้ KDF ที่ทำงานช้ากว่า เช่น Argon2id

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

เหตุใดการใส่เกลืออย่างเดียวจึงไม่เพียงพอ

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

ระบบรักษาความปลอดภัยรหัสผ่านที่แท้จริงในปี 2026 ประกอบด้วยการป้องกันสี่ชั้น Argon2id ที่ใช้ salt ขนาด 16 ไบต์ต่อผู้ใช้ ช่วยจัดการการจัดเก็บข้อมูล Pepper ซึ่งเป็นตัวเลือกเสริมแต่คุ้มค่าสำหรับระบบที่มีความอ่อนไหว ช่วยป้องกันการขโมยข้อมูลเฉพาะฐานข้อมูล การตรวจสอบสิทธิ์แบบหลายปัจจัยช่วยป้องกันการโจมตีด้วยการยัดข้อมูลประจำตัวและการฟิชชิ่งส่วนใหญ่ การตรวจสอบการละเมิดอย่างต่อเนื่อง — บริการต่างๆ เช่น Have I Been Pwned และ API ของมัน — จะตรวจจับได้ทันทีที่ข้อมูลประจำตัวของผู้ใช้ปรากฏในการรั่วไหล เพื่อบังคับให้ผู้ใช้รีเซ็ตรหัสผ่าน

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

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.