ตัวสร้าง Bcrypt

SHA-256 และ MD5 ถูกออกแบบมาให้ทำงานเร็ว — GPU สมัยใหม่สามารถคำนวณ SHA-256 hashes ได้หลายพันล้านรายการต่อวินาที ความเร็วระดับนั้นเป็นอันตรายมากสำหรับการ hashing รหัสผ่าน: ผู้โจมตีสามารถ brute-force การเดารหัสผ่านได้หลายพันล้านครั้งต่อวินาที ส่วน Bcrypt จงใจให้ทำงานช้า: การคำนวณ hash เพียงครั้งเดียวใช้เวลาหลายมิลลิวินาทีที่ cost factor 10 ซึ่งจำกัดผู้โจมตีให้เหลือเพียงไม่กี่ร้อยครั้งต่อวินาทีแม้จะมีฮาร์ดแวร์ที่ทรงพลัง ห้ามใช้ MD5, SHA-1 หรือแม้แต่ SHA-256 โดยตรงสำหรับการ hashing รหัสผ่าน — ให้ใช้ bcrypt, Argon2 หรือ scrypt แทน

Cost factor 10 (2^10 = 1,024 iterations) เป็นค่าต่ำสุดที่ OWASP แนะนำสำหรับแอปพลิเคชันส่วนใหญ่และให้ผลลัพธ์ hash ในเวลาประมาณ 100ms บนฮาร์ดแวร์สมัยใหม่ ควรใช้ cost factor 12 สำหรับระบบที่จัดการข้อมูลที่อ่อนไหวเช่นบัญชีการเงิน การเพิ่มขึ้นแต่ละขั้นจะทำให้เวลาคำนวณเพิ่มขึ้นเป็นสองเท่า: factor 12 จะใช้เวลานานกว่า factor 10 ถึง 4 เท่า ทดสอบบนฮาร์ดแวร์เซิร์ฟเวอร์จริงของคุณและตั้งเป้าให้ได้ 100-300ms ต่อ hash — ช้าพอที่จะขัดขวางผู้โจมตี และเร็วพอที่จะไม่ทำให้ผู้ใช้ที่ใช้งานจริงหงุดหงิด ห้ามต่ำกว่า factor 10 ในระบบ production

Bcrypt สร้าง cryptographically random salt ขนาด 22 ตัวอักษรสำหรับแต่ละ hash และฝังไว้ใน output string ค่า salt ช่วยรับประกันว่าแม้ผู้ใช้สองคนจะมีรหัสผ่านเหมือนกัน แต่จะได้ค่า hash ที่ต่างกัน วิธีนี้จะช่วยป้องกัน rainbow tables (การจับคู่ hash-to-password ที่คำนวณไว้ล่วงหน้า) และป้องกันไม่ให้ผู้โจมตีเห็นว่าบัญชีสองบัญชีใช้รหัสผ่านเดียวกัน ค่า salt จะถูกจัดเก็บเป็นส่วนหนึ่งของ hash string ($2b$10$<22-char-salt><31-char-hash>) ดังนั้นคุณจึงไม่จำเป็นต้องแยกเก็บมัน

ไม่ได้ Bcrypt (เช่นเดียวกับฟังก์ชัน cryptographic hash ที่เหมาะสมทั้งหมด) เป็นฟังก์ชันแบบทางเดียว — ไม่มีวิธีที่จะย้อนกลับได้ วิธีเดียวในการ "หา" รหัสผ่านจาก bcrypt hash คือการ brute force: ลองเดารหัสผ่านนับล้านตัวจนกว่าจะเจอที่ตรงกัน นี่คือเหตุผลว่าทำไมความช้าของ bcrypt จึงเป็นคุณสมบัติความปลอดภัย ไม่ใช่บั๊ก ในการตรวจสอบว่ารหัสผ่านถูกต้องหรือไม่ คุณต้องใช้ฟังก์ชัน verify — ซึ่งจะทำการ re-hash ข้อมูลนำเข้าด้วย salt ที่เก็บไว้ใน hash และเปรียบเทียบผลลัพธ์

แท็บ Verify จะดึงค่า salt และ cost factor ที่ฝังอยู่ใน hash string เดิมออกมา รัน bcrypt กับรหัสผ่านที่ป้อนเข้าไปโดยใช้พารามิเตอร์เหล่านั้น และเปรียบเทียบผลลัพธ์กับ hash ที่เก็บไว้ หากตรงกัน แสดงว่ารหัสผ่านถูกต้อง นี่คือวิธีการทำงานของระบบยืนยันตัวตนในเว็บแอปพลิเคชัน: ค่า hash ที่เก็บไว้นั้นไม่มีวันเปลี่ยนแปลง และคุณตรวจสอบความพยายามในการล็อกอินโดยการคำนวณหา hash ใหม่ด้วย salt เดิม กระบวนการนี้ใช้เวลาเท่ากับการสร้าง hash ซึ่งเป็นความตั้งใจในการออกแบบ

มี Bcrypt จะทำการตัดรหัสผ่านที่ 72 bytes หมายความว่ารหัสผ่านที่ยาวมาก (เกิน 72 ASCII characters หรือน้อยกว่าสำหรับ Unicode characters ที่เป็นหลายไบต์) จะให้ค่า hash เดียวกันไม่ว่าจะตามด้วยอะไรก็ตามหลัง byte ที่ 72 — "password123" และ "password123abc..." จะได้ค่า hash เดียวกันหาก 72 ไบต์แรกตรงกัน สำหรับแอปพลิเคชันที่ผู้ใช้อาจป้อนรหัสผ่านยาวกว่า 72 ตัวอักษร วิธีแก้ปัญหาทั่วไปคือการนำรหัสผ่านไปผ่าน SHA-256 ก่อน จากนั้นจึงส่ง hash ให้กับ bcrypt (ซึ่ง hash จะมีขนาด 64 ASCII characters ซึ่งอยู่ภายในขีดจำกัดอย่างปลอดภัย)

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