แฮช/การเข้ารหัส
Bcrypt Hash + Verify
แฮชรหัสผ่านด้วย bcrypt (พร้อม salt แบบสุ่มและปรับ cost ได้) และตรวจสอบรหัสผ่านกับแฮช bcrypt ที่มีอยู่
Bcrypt is a deliberately slow password-hashing algorithm: unlike MD5 or SHA-256, it intentionally requires heavy computation so that brute-forcing passwords stays impractical even if a database of hashes leaks.
How to use it
- Hash: enter a password and set a cost factor — a higher number means slower, more secure hashing.
- Every hash call generates a fresh random salt, so the same password produces a different hash each time — that's expected and normal.
- Verify: paste a password and an existing bcrypt hash to check whether they match, without hashing manually yourself.
Common uses
- Manually checking that a backend hashes passwords correctly before storing them.
- Generating a test bcrypt hash for seed data or fixtures during development.
- Debugging a failed login by comparing an entered password against the stored hash.
Things to keep in mind
Pick a cost factor that keeps hashing around 100-300ms on your target server — a balance between security and login-time load.
Bcrypt truncates passwords longer than 72 bytes — characters beyond that limit are ignored by the algorithm.
บทความเกี่ยวกับเครื่องมือนี้: Bcrypt: เหตุใดรหัสผ่านจึงถูกแฮชอย่างช้า ๆ ไม่ใช่เร็ว
คำถามที่พบบ่อย
ทำไม bcrypt ถึงมีค่า "cost" หรือจำนวนรอบ?
ค่า cost กำหนดว่าการแฮชจะถูกทำซ้ำภายในกี่ครั้ง ดังนั้นการแฮชจะช้าลงแบบทวีคูณเมื่อค่านี้เพิ่มขึ้น สิ่งนี้ช่วยให้คุณจงใจทำให้มันช้าพอที่จะต้านทานการบรูทฟอร์สได้ แม้ฮาร์ดแวร์จะเร็วขึ้นก็ตาม
ทำไมแฮช bcrypt ถึงมีความยาวเท่ากันเสมอไม่ว่ารหัสผ่านจะเป็นอย่างไร?
Bcrypt สร้างแฮชความยาวคงที่ (ปกติ 60 ตัวอักษร) ที่เข้ารหัสเวอร์ชันอัลกอริทึม ค่า cost, salt และแฮชไว้ด้วยกัน ความยาวจึงไม่ขึ้นกับความยาวของรหัสผ่านต้นฉบับ
bcrypt ต้องมีช่อง salt แยกต่างหากหรือไม่?
ไม่ต้อง salt ถูกสร้างขึ้นอัตโนมัติและฝังอยู่ในสตริงผลลัพธ์โดยตรง จึงไม่ต้องเก็บหรือจัดการแยกต่างหาก มันจะรวมอยู่เสมอเมื่อคุณตรวจสอบรหัสผ่านกับแฮช
bcrypt มีข้อจำกัดความยาวของรหัสผ่านหรือไม่?
มี bcrypt ประมวลผลเฉพาะ 72 ไบต์แรกของรหัสผ่านเท่านั้น — ส่วนที่ยาวเกินกว่านั้นจะถูกตัดทิ้งโดยไม่มีการแจ้งเตือน ในทางปฏิบัติเรื่องนี้แทบไม่เป็นปัญหา แต่ควรจำไว้เมื่อทำงานกับรหัสผ่านที่ยาวมากหรืออักขระที่ไม่ใช่ ASCII ซึ่งตัวอักษรหนึ่งตัวอาจใช้หลายไบต์
เหตุใดจึงยังแนะนำ bcrypt ทั้งที่มี Argon2 แล้ว?
bcrypt ผ่านการพิสูจน์ในทางปฏิบัติมานานหลายทศวรรษ ได้รับการรองรับอย่างกว้างขวางในทุกภาษาและเฟรมเวิร์ก และยังคงเป็นตัวเลือกที่เชื่อถือได้อย่างสมบูรณ์ Argon2 ถูกแนะนำให้เป็นตัวเลือกอันดับแรกสำหรับระบบใหม่เพราะป้องกันการโจมตีด้วย GPU/ASIC ได้ดีกว่า แต่ bcrypt ก็ไม่ได้ถือว่าไม่ปลอดภัย เพียงแต่ทนทานต่อฮาร์ดแวร์เฉพาะทางน้อยกว่า