PBKDF2 Hash Generator: สร้าง Password Hash ในเบราว์เซอร์

เวลาจะเก็บ password ของผู้ใช้ในระบบ กฎข้อแรกคือห้ามเก็บเป็น plaintext แน่นอน แต่รู้หรือไม่ว่าการเอา password ไปผ่าน SHA-256 ธรรมดาเพียงรอบเดียวก็ยังไม่ปลอดภัยพอ เพราะ GPU สมัยใหม่สามารถคำนวณ hash ได้เป็นพันล้านครั้งต่อวินาที ทำให้ attacker สามารถ brute force รหัสผ่านธรรมดาได้ในเวลาไม่นาน PBKDF2 (Password-Based Key Derivation Function 2) คือมาตรฐานที่ NIST รับรอง ออกแบบมาเพื่อแก้ปัญหานี้โดยเฉพาะ ด้วยการทำให้การ hash password แต่ละครั้ง "ช้าลงอย่างตั้งใจ" เพื่อทำลายความได้เปรียบของเครื่องจักรที่เร็วกว่า

ถ้าอยากลองสร้าง hash ด้วยตัวเอง ใช้ PBKDF2 Hash Generator ได้ฟรีทันที ไม่ต้องสมัครสมาชิก ไม่ต้องติดตั้งไลบรารี แค่ใส่ password เลือก salt, จำนวน iterations และ hash function แล้วกดสร้าง ผลลัพธ์จะออกมาเป็น hash hex พร้อม salt hex ที่นำไปใช้ต่อได้เลย

จุดเด่นสำคัญคือเครื่องมือนี้ประมวลผลผ่าน Web Crypto API ใน browser ของคุณ 100% password ที่คุณพิมพ์ไม่ถูกส่งขึ้นเซิร์ฟเวอร์ใด ๆ จึงทดลองได้อย่างมั่นใจ บทความนี้จะพาไปดูวิธีใช้งานทีละขั้น หลักการทำงานเบื้องหลัง PBKDF2 และตัวอย่างการนำไปใช้ในสถานการณ์จริง

ทำไมต้องใช้ PBKDF2 Hash Generator?

• ทดสอบพารามิเตอร์ก่อนใช้จริง — ลองเปลี่ยนจำนวน iterations หรือ hash function แล้วเห็นผลลัพธ์ทันที ช่วยตัดสินใจว่าจะตั้งค่าอะไรใน production
• มาตรฐานที่ NIST รับรอง — PBKDF2 เป็น key derivation function ที่อยู่ในมาตรฐานสากลและถูกใช้แพร่หลายที่สุดตัวหนึ่ง ไม่ใช่อัลกอริทึมเฉพาะทางที่ยังไม่ผ่านการพิสูจน์
• ทำงานในเครื่องทั้งหมด — ประมวลผลด้วย Web Crypto API ฝั่ง client password และ salt ไม่เดินทางออกจาก browser ของคุณแม้แต่ไบต์เดียว
• มีโหมด verify ในตัว — สร้าง hash ซ้ำด้วย salt และ iterations เดิมเพื่อยืนยันว่า hash ตรงกัน เหมือนกับ flow ตรวจสอบ password ตอน login จริง
• รองรับ 3 hash function — เลือกได้ระหว่าง SHA-256, SHA-384 และ SHA-512 เพื่อเทียบผลลัพธ์และความเหมาะสมของแต่ละแบบ
• พร้อม preset iterations — มีตัวเลือกสำเร็จรูป 1,000 / 10,000 / 100,000 / 600,000 รองรับทั้งการทดลองเร็ว ๆ และค่าแนะนำของ OWASP

ฟีเจอร์หลัก

รายละเอียดที่น่าสังเกตเพิ่มเติม:

• การ derive ใช้ crypto.subtle.deriveBits ซึ่งเป็นวิธีมาตรฐานเดียวกับที่คุณจะเขียนในโค้ดจริง ผลลัพธ์จึงตรงกับที่ได้จาก Node.js, Python หรือภาษาอื่นที่ implement PBKDF2 ตามมาตรฐาน
• salt แบบสร้างอัตโนมัติใช้ค่าสุ่มที่เหมาะกับงาน cryptographic ไม่ใช่การสุ่มแบบธรรมดา
• ทุกอย่างรันฝั่ง client ผ่าน Web Crypto API — ไม่ส่งข้อมูลขึ้นเซิร์ฟเวอร์ ไม่มี log ไม่มี analytics เก็บ input

วิธีสร้าง PBKDF2 Hash

1. เปิด PBKDF2 Hash Generator ใน browser — ใช้งานได้ทันทีไม่ต้องติดตั้ง
2. ใส่ password ที่ต้องการ hash ในช่อง password แล้วเลือก salt ว่าจะพิมพ์เองหรือกดให้ระบบสร้างแบบสุ่มอัตโนมัติ
3. เลือก hash function เป็น SHA-256, SHA-384 หรือ SHA-512 ตามความต้องการ (ถ้าไม่แน่ใจ SHA-256 เป็นตัวเลือกที่ปลอดภัย)
4. เลือกจำนวน iterations จาก preset — ลอง 1,000 ก่อนเพื่อความเร็วตอนทดลอง แล้วค่อยเลื่อนไป 600,000 ซึ่งเป็นค่าที่ OWASP แนะนำสำหรับ PBKDF2-HMAC-SHA256
5. กดสร้างเพื่อรับ hash hex พร้อม salt hex จากนั้น copy ผลลัพธ์ไปเก็บ หรือสลับไปโหมด verify เพื่อทดสอบว่า password ชุดเดิมสร้าง hash เดิมได้จริง

PBKDF2 ปกป้อง Password อย่างไร

KDF ทำหน้าที่อะไร — ฟังก์ชันการสร้างคีย์ (Key Derivation Function) คือฟังก์ชันที่เปลี่ยน password ซึ่งเป็นข้อความที่มนุษย์เลือก (มักมี entropy ต่ำ) ให้กลายเป็นค่า bit string ยาวที่ดูสุ่มเหมือนคีย์จริง ความต่างจาก hash function ธรรมดาคือ KDF ถูกออกแบบให้ "ช้า" โดยเจตนา เพราะฝั่งผู้ใช้ต้องคำนวณแค่ครั้งเดียวต่อการ login แต่ฝั่ง attacker ที่ลองเดา password นับล้านรายการต้องจ่ายต้นทุนนั้นซ้ำทุกครั้ง

บทบาทของ salt — salt คือค่าสุ่มที่ผสมเข้าไปกับ password ก่อนการคำนวณ hash จุดประสงค์หลักคือป้องกันการใช้ rainbow table และทำให้ผู้ใช้ที่ตั้งรหัสผ่านเหมือนกันมี hash ต่างกัน salt ไม่จำเป็นต้องเป็นความลับ เก็บไว้เคียงข้าง hash ได้เลย แต่ต้องไม่ซ้ำกันในแต่ละผู้ใช้

ทำไม iterations จึงสำคัญ — PBKDF2 จะวนคำนวณ HMAC ซ้ำตามจำนวน iterations ที่กำหนด ยิ่งเยอะ การ brute force ก็ยิ่งช้าลงเป็นเงาตาม เช่นจาก 1,000 เป็น 600,000 รอบหมายถึง attacker ต้องใช้เวลามากขึ้น 600 เท่าในการลอง password เดียวกัน นี่คือเหตุผลที่ OWASP แนะนำ 600,000 iterations สำหรับ PBKDF2-HMAC-SHA256 ในปัจจุบัน

การเลือก SHA variant — SHA-256 เป็นตัวมาตรฐานที่มีคำแนะนำ iterations ชัดเจนที่สุด SHA-384 และ SHA-512 ให้ผลลัพธ์ยาวขึ้น และ SHA-512 อาจทำงานได้เร็วกว่าบนสถาปัตยกรรม 64-bit ซึ่งบางครั้งเปลี่ยนเป็นข้อดีเมื่อเทียบต้นทุนกับ attacker ส่วนใหญ่แล้วเลือกตัวใดก็ได้ที่ implement ถูกต้องและตั้ง iterations สูงพอ

การ verify โดยไม่เก็บ password — ระบบไม่ต้องเก็บ password ต้นฉบับเลย ตอนผู้ใช้ login ให้เอา password ที่กรอกมา derive ซ้ำด้วย salt และ iterations เดิมที่เก็บไว้ แล้วเทียบกับ hash ที่มีอยู่ ถ้าตรงกันแปลว่า password ถูก รูปแบบการเก็บในฐานข้อมูลจึงแค่นี้:

{"algo":"SHA-256","iterations":600000,
 "salt":"e3b0c442...","hash":"9f86d081..."}

กรณีใช้งานจริง

ทำ Prototype ระบบ Login ให้เสร็จเร็ว

สมมติคุณกำลังทำ side project เป็น API ยิงงานแบบ serverless และต้องการฟีเจอร์สมัครสมาชิกแบบง่าย ๆ คุณสามารถใช้ tool นี้สร้าง hash สำหรับ seed user ได้ทันที — ใส่ password ที่ต้องการ เลือก SHA-256 ที่ 600,000 iterations กดสร้าง แล้วเอา hash + salt ไปใส่ใน seed script โดยไม่ต้องเขียนโค้ด derive เองก่อน พอ prototype รันได้ค่อยย้ายไปคำนวณใน backend ตอน runtime

ปรับ Iteration Count ให้สมดุลระหว่างความปลอดภัยและความเร็ว

ทีมหลายทีมเจอคำถามว่า 600,000 iterations จะทำให้ server หรือมือถือของผู้ใช้ช้าเกินไปหรือไม่ ลองจับเวลาด้วยการกดสร้างใน tool ที่ preset ต่าง ๆ บนอุปกรณ์จริงที่คุณ deploy ด้วย ถ้าเครื่องเป้าหมายคำนวณ 600,000 รอบแล้วใช้เวลาไม่ถึงครึ่งวินาทีก็น่าจะปลอดภัยที่จะใช้ค่าแนะนำ ถ้าช้ากว่านั้นมาก (เช่นบนอุปกรณ์ embedded) คุณจะเห็นชัดว่า 100,000 รอบให้ trade-off แบบไหน ตัดสินใจจากข้อมูลจริงแทนการเดา

สร้าง Test Vector สำหรับ Unit Test

เวลาเขียนฟังก์ชัน hashing ในโปรเจกต์ คุณต้องมี test vector เพื่อยืนยันว่า implementation ทำงานถูกต้อง ใช้ tool นี้สร้างกรณีทดสอบด้วย input ที่คุมได้ เช่น password test1234, salt กำหนดเองเป็นค่า fixed และ iterations ที่ 10,000 จากนั้น copy hash hex ไปใส่ใน assertion ของ unit test — ถ้าโค้ดของคุณ derive ได้ค่าตรงกันแปลว่า implementation เข้ากันได้กับ Web Crypto API มาตรฐาน

เรียนรู้คอนเซปต์ Crypto อย่างปลอดภัย

ถ้ากำลังสอนหรือเรียนเรื่อง password storage ให้เห็นภาพว่า iterations เปลี่ยนผลลัพธ์อย่างไร tool นี้ตอบโจทย์ได้ดีเพราะลองได้ทันทีโดยไม่ต้องตั้งสภาพแวดล้อม dev ขึ้นมา ลอง hash password เดียวกันที่ 1,000 และ 600,000 iterations แล้วเทียบ hash ที่ได้ หรือเปลี่ยน salt ตัวเดียวแล้วดูว่า hash เปลี่ยนทั้งค่าเลย ประสบการณ์แบบ interactive ช่วยให้เข้าใจแนวคิดลึกกว่าการอ่านทฤษฎีเพียงอย่างเดียว

แนวทางปฏิบัติที่ดี

• ใช้ iterations สูงตามคำแนะนำล่าสุด — เป้าหมายคือ 600,000 รอบสำหรับ PBKDF2-HMAC-SHA256 ตามแนวทางของ OWASP และปรับขึ้นเมื่อฮาร์ดแวร์เร็วขึ้น
• ใช้ salt สุ่มที่ไม่ซ้ำต่อผู้ใช้ — อย่า reuse salt ระหว่าง account และอย่าใช้ค่าที่คาดเดาได้เช่น username หรือ timestamp
• อย่าลืมเก็บพารามิเตอร์คู่กับ hash — เก็บ hash function, iterations และ salt ไว้พร้อมกันเสมอ ไม่งั้นจะ verify ไม่ได้และไม่สามารถอัปเกรดค่าได้ในอนาคต
• อย่าเขียน implementation เอง — ใช้ไลบรารีมาตรฐานหรือ Web Crypto API แทนการเขียน PBKDF2 เอง เพราะจุดบอบบางมักอยู่ที่รายละเอียดที่มองไม่เห็น
• เทียบ hash ตอน verify อย่างคงที่เวลา (constant-time) — หลีกเลี่ยงการเทียบ string แบบปกติ เพื่อป้องกัน timing attack ในโค้ดจริง
• อย่าใช้ tool ทดสอบกับ password จริงที่ sensitive — ถึงแม้จะทำงานในเครื่อง 100% แต่ password ตัวอย่างใน demo ควรเป็นค่าที่ไม่เกี่ยวกับบัญชีจริงของคุณ

เมื่อพร้อมจะลองแล้ว เปิด PBKDF2 Hash Generator ใส่ password ตัวอย่างสักชุด ลองเลื่อน iterations ดูว่าความรู้สึกตอนคำนวณเปลี่ยนไปแค่ไหน แล้วคุณจะเข้าใจทั้งหลักการและ trade-off ของการเลือกพารามิเตอร์ได้ในเวลาไม่กี่นาที — ฟรี ไม่มีค่าใช้จ่าย และข้อมูลของคุณไม่หลุดออกจากเบราว์เซอร์

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Hash Generator — สร้าง hash มาตรฐาน MD5, SHA-1, SHA-256 ฯลฯ สำหรับข้อความและไฟล์ ใช้ตรวจความสมบูรณ์ของข้อมูล
• Password Hash Verifier — ตรวจสอบ password กับ hash ที่มีอยู่เพื่อยืนยันว่าตรงกัน ครอบคลุมหลายรูปแบบ hashing
• PHP Password Hash Generator — สร้าง password hash สำหรับ PHP เช่น bcrypt ที่ใช้กับ password_verify() ในโปรเจกต์ PHP

ขอให้ hash อย่างสนุก!

คำถามที่พบบ่อย

ถ: PBKDF2 ต่างจาก SHA-256 ธรรมดาอย่างไร?

ตอบ: SHA-256 ธรรมดาคำนวณเร็วมาก เหมาะกับการตรวจความสมบูรณ์ของข้อมูลแต่ไม่เหมาะกับ password เพราะ attacker ลองเดาได้เร็วเช่นกัน PBKDF2 ใช้ HMAC-SHA256 วนซ้ำหลายพันถึงหลายแสนรอบ ทำให้การลองเดาแต่ละครั้งแพงขึ้นมหาศาล จึงเป็นตัวเลือกที่ถูกต้องสำหรับการเก็บ password

ถ: salt เก็บเป็นความลับได้ไหม หรือต้องเก็บไว้ที่ไหน?

ตอบ: salt ไม่จำเป็นต้องเป็นความลับ มีหน้าที่แค่ทำให้ hash ของแต่ละผู้ใช้ต่างกันและทำลาย rainbow table เก็บไว้เคียงข้าง hash ในฐานข้อมูลได้เลย แต่ต้องสุ่มใหม่ให้ไม่ซ้ำกันในแต่ละ account

ถ: ทำไม OWASP แนะนำ 600,000 iterations?

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

ถ: เครื่องมือนี้ปลอดภัยแค่ไหน ใส่ password จริงได้ไหม?

ตอบ: ทุกการคำนวณรันฝั่ง client ผ่าน Web Crypto API ใน browser ของคุณ password และ salt ไม่ถูกส่งออกไปยังเซิร์ฟเวอร์ใด ๆ อย่างไรก็ตามแนวปฏิบัติที่ดีคือใช้ password ตัวอย่างสำหรับการทดลอง และสงวน password จริงไว้ใช้ในระบบที่คุณควบคุมเอง

ถ: ผลลัพธ์จาก tool นี้ใช้ตรงกับ implementation ในภาษาอื่นได้ไหม?

ตอบ: ได้ เพราะ PBKDF2 เป็นมาตรฐานที่กำหนดผลลัพธ์ไว้ชัดเจน ถ้า input ตรงกัน (password, salt, iterations, hash function) ผลที่ได้จาก Python, Node.js, Java หรือ PHP ที่ implement ถูกต้องจะเท่ากับที่ tool สร้างให้พอดี เหมาะกับการทำ test vector