Hashing — เครื่องบดเนื้อที่บดได้แต่ย้อนกลับไม่ได้#

ผมขอใช้ analogy ที่ผมเคยใช้ใน IT Foundation EP.06 ครับ (อาจคุ้นถ้าคุณอ่านมาก่อน) — Hashing เหมือนเครื่องบดเนื้อ

ลองนึกภาพคุณใส่เนื้อวัวก้อนนึงเข้าเครื่องบดเนื้อ — กดปุ่ม — ได้เนื้อบดออกมา. คำถามคือ — คุณเอาเนื้อบดนั้นกลับเข้าเครื่อง กดย้อนกลับ ได้วัวคืนมาไหม? ไม่ได้ครับ. เนื้อบดคือผลของกระบวนการที่ “ทางเดียว” — ไปได้ ย้อนไม่ได้

Hashing ทำงานแบบเดียวกัน. มันคือฟังก์ชันคณิตศาสตร์ที่รับ input (เช่น password ของคุณ) → คำนวณ → คายผลออกมาเป็นสตริงยาวๆ ที่เรียกว่า hash. และเหมือนเครื่องบดเนื้อ — เอา hash กลับมา ย้อนเป็น password ไม่ได้. นี่คือคุณสมบัติเรียกว่า One-Way Function (ฟังก์ชันทางเดียว) — เป็นรากฐานของ security ทั่วทั้งวงการ

ลองดูตัวอย่างจริง — ถ้าคุณ hash คำว่า “password123” ด้วย SHA-256 จะได้:

ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

64 ตัวอักษร hex. และถ้าคุณ hash “password124” (เปลี่ยนเลขท้ายตัวเดียว) จะได้:

38a44b21fc99fc7a.. — สตริงคนละชุดเลย. เปลี่ยน input 1 ตัวอักษร → output เปลี่ยนทั้งสตริง. นี่คือคุณสมบัติเรียกว่า Avalanche Effect — เป็นสัญญาณว่า hash function ตัวนั้นแข็งแรง

แล้วระบบเก็บ password ใช้ hash ยังไง? — ขั้นตอนเป็นแบบนี้ครับ

ตอนสมัครสมาชิก:

1. ผู้ใช้พิมพ์ password “MyPass123!” → ส่งเข้า server
2. Server hash → ได้ “ef92b778…”
3. Server เก็บ ของบดในเครื่องบด (= hash) ลง DB. ไม่เก็บของจริง (= password) ลง DB

ตอน login:

1. ผู้ใช้พิมพ์ password “MyPass123!” → ส่งเข้า server
2. Server hash อีกครั้ง → ได้ “ef92b778…”
3. Server เปรียบเทียบกับ hash ที่เก็บใน DB → ตรงกัน = ผ่าน. ไม่ตรงกัน = ปฏิเสธ

ที่สำคัญคือ — server เองก็ไม่เคยเห็น password จริงของคุณหลังขั้นตอน hash. แม้แต่ admin ของระบบ — ถ้าเปิด DB ขึ้นมา ก็เห็นแค่ hash. ถ้า hash function แข็งแรงพอ — admin ก็อ่าน password ของคุณไม่ออก

ผลลัพธ์ — ถ้า DB รั่ว → โจรเห็น hash → แต่ย้อนกลับเป็น password ไม่ได้ (ในทางทฤษฎี). ความเสียหายจำกัด. ลูกค้าไม่เดือดร้อนถึงเว็บอื่น

ฟังดูสวยใช่ไหมครับ. แต่ในชีวิตจริง — เรื่องไม่ง่ายแบบนั้น. hash function ทุกตัวเท่ากันไหม? คำตอบคือ — ไม่. และนี่คือหัวข้อถัดไป

มุมผู้บริหาร: คำถามที่ผู้บริหารควรถาม CTO/CIO ในประชุมต่อไป — “ระบบทั้งหมดของบริษัทเราที่เก็บ password ของลูกค้าหรือพนักงาน — เก็บแบบ hash ทุกระบบหรือยัง? มีตัวไหนเก็บแบบ Plain Text หรือเก็บแบบ encryption (ที่ย้อนได้) อยู่บ้าง?”. ถ้า IT ตอบไม่ได้ภายใน 1 อาทิตย์ = ต้องลง audit เป็นการด่วน. และถ้าเจอตัวที่ยังเก็บแบบผิดอยู่ — ต้อง migration ทันที. กระบวนการ migration ปกติคือ — บังคับให้ user reset password ครั้งถัดไปที่ login เพื่อให้ระบบ hash ใหม่ตอนกรอก. ไม่ต้องลงทุน tool ใหม่ — ใช้ระยะเวลาและวินัยของทีม dev เป็นหลัก

MD5 — เกิด 1991, ตาย 2004 — แต่ยังเจอใน legacy เยอะมาก#

MD5 (Message-Digest 5) — สร้างโดย Ronald Rivest (R ใน RSA) ในปี 1991. ออกแบบให้ hash data → ได้ output 128 bit (32 ตัว hex). ในยุค 1990s — MD5 ใช้ทั่วโลก. ทุกเว็บ ทุกระบบ. MD5 = มาตรฐานวงการ

แต่ปัญหามาในปี 2004 — นักวิจัยจีนชื่อ Wang Xiaoyun พบ MD5 collision attack — แปลว่าเธอหาวิธีสร้าง input 2 ตัวที่ต่างกัน แต่ hash ออกมาได้ค่าเดียวกัน. ในทางทฤษฎี hash function ที่ดี — input ต่างกัน ต้องให้ output ต่างกันเสมอ. ถ้าหา collision ได้ = hash function เสีย

หลังปี 2004 — ทุกๆ ปี นักวิจัยปรับปรุงเทคนิคให้หา collision ของ MD5 ได้เร็วขึ้นเรื่อยๆ. ในปี 2025 — laptop ทั่วไปหา MD5 collision ได้ในไม่กี่วินาที. นั่นแปลว่า — โจรที่มี hash ของ password ใน DB — สามารถสร้าง password ปลอมที่ hash ตรงกันได้ = login ผ่านโดยไม่รู้ password จริง

วงการ security ประกาศ MD5 เป็น “deprecated” (ตายแล้ว ห้ามใช้) ตั้งแต่ราวๆ ปี 2008. ทุกหนังสือเรียน security ในวันนี้บอกตรงกัน — MD5 ไม่ควรใช้ในระบบใดๆ ที่เกี่ยวกับ security

แต่ — และนี่คือ “แต่” ที่สำคัญสำหรับผู้บริหาร — ในปี 2026 ยังเจอ MD5 ใน legacy system ของบริษัทไทยเยอะมาก. ส่วนใหญ่เป็นระบบที่สร้างมาก่อนปี 2010 และไม่เคย migrate. ตัวอย่างสมมติที่ตรงกับเหตุการณ์จริง — ระบบเก็บเงินเดือนพนักงานเขียนปี 2008 — เก็บ password admin เป็น MD5 ตรงๆ. 17 ปีของ technical debt ในระบบเดียว. นี่คือ pattern คลาสสิคที่นักวิจัย security ออกมาเตือนบ่อยในวงการบริษัทไทย

SHA-1 — เกิด 1995, ตาย 2017 (SHAttered) — Google ฆ่ามันด้วยตัวเอง#

SHA-1 (Secure Hash Algorithm 1) — สร้างโดย NSA ในปี 1995 — ออกแบบมาให้ดีกว่า MD5. output 160 bit (40 ตัว hex). ในยุค 2000s — SHA-1 = มาตรฐานทั่ววงการ. SSL certificates / Git commits / password hash — ทุกอย่างใช้ SHA-1

วงการเริ่มสงสัย SHA-1 ตั้งแต่ปี 2005 (นักวิจัยพบ theoretical weakness) — แต่ยังไม่มีใครทำ collision ของจริงให้ดู. จนปี 2017 — Google + CWI Amsterdam ประกาศ SHAttered attack — สร้าง PDF 2 ไฟล์ที่หน้าตาต่างกัน แต่ SHA-1 hash ตรงกัน. ใช้ computing power 6,500 ปี CPU + 110 ปี GPU. แพง — แต่ทำได้จริง

หลัง SHAttered ปี 2017 — SHA-1 ตายอย่างเป็นทางการ. Browser หยุดยอมรับ SHA-1 certificates. Git ยังใช้ SHA-1 อยู่ (กำลัง migrate ไป SHA-256) แต่บอกตรงๆ ว่ารู้ตัวว่าเสี่ยง. ระบบใดๆ ที่ยังใช้ SHA-1 hash password ปี 2026 = ต้อง migrate ทันที

SHA-256 / SHA-3 — ยังใช้ได้ แต่ ไม่ใช่ตัวเลือกที่ดีสำหรับ password#

SHA-256 (ส่วนหนึ่งของ SHA-2 family) — เกิดปี 2001 — output 256 bit. ปลอดภัยกว่า SHA-1 มาก. จนถึงปี 2026 — ยังไม่มีใคร collision attack ได้

SHA-3 — เกิดปี 2015 — ตัวใหม่กว่า, สถาปัตยกรรมต่างจาก SHA-2 family. ออกแบบมาเผื่อ SHA-2 พังในอนาคต — มี backup พร้อม

ทั้ง SHA-256 และ SHA-3 = ยังใช้ได้ในปี 2026 สำหรับ general hashing (เช่น integrity check ของไฟล์, digital signature, blockchain). แต่ — สำหรับ hash password — ไม่ใช่ตัวเลือกที่ดี

อ้าว ทำไมล่ะครับ?

ทำไม SHA-256 ดีพอสำหรับงานอื่น แต่ห่วยสำหรับ password — เพราะมัน “เร็วเกินไป”#

ตรงนี้คือจุดที่คนทั่วไปงง — และต้องอ่านช้าๆ ครับ

SHA-256 ออกแบบมาให้ เร็ว. เพราะวงการใช้มันในงานที่ต้อง hash ข้อมูลปริมาณมหาศาล — verify ไฟล์ขนาดเป็น GB, blockchain ที่ต้อง hash transaction ล้านครั้งต่อวินาที. ยิ่งเร็ว = ยิ่งดี

ปัญหาคือ — สำหรับ password hash ความเร็วคือศัตรู

ลองคิดดู — สมมติโจรได้ DB ของเว็บคุณ. ใน DB มี hash ของ password ลูกค้า 1 ล้านคน. โจรจะทำ brute force attack — ลองเดา password ทุกความเป็นไปได้ → hash → เทียบกับใน DB → ถ้าตรง = ได้ password นั้น

ใน password 8 ตัวอักษร — ความเป็นไปได้ทั้งหมดประมาณ 6.6 quadrillion (66 ล้านล้านล้าน). ถ้าโจรใช้ SHA-256 + GPU สมัยใหม่ — hash ได้ประมาณ 100 พันล้าน hash ต่อวินาที (ไม่ใช่ exaggeration — RTX 4090 ทำได้จริง). คำนวณดู — 6.6 quadrillion ÷ 100 พันล้าน = 66,000 วินาที = 18 ชั่วโมง. แปลภาษาคน — โจรลอง password 8 ตัวอักษรทุกความเป็นไปได้ ใช้เวลาแค่วันเดียว

นี่คือทำไม SHA-256 ห่วยสำหรับ password — มันเร็วเกินไปสำหรับฝั่งโจร

แล้วทางออกคืออะไร? — ใช้ hash function ที่ออกแบบให้ “ช้าตั้งใจ” สำหรับ password โดยเฉพาะ. ฟังดูแปลกใช่ไหมครับ — ช้าตั้งใจ = ดี. แต่นี่คือ insight ที่เปลี่ยนวงการ password hash ทั้งหมดในยุค 2000s ขึ้นไป

Analogy ง่ายๆ — SHA-256 = เครื่องบดเนื้อความเร็วสูง 5,000 รอบต่อนาที — บดเนื้อ 1 ตันใน 10 นาที. bcrypt = เครื่องบดที่ตั้งใจให้ช้า 10 รอบต่อนาที — บดเนื้อ 1 ก้อนใช้เวลา 1 วินาที. ตอนคุณ login ครั้งเดียว — ความช้านี้ไม่รู้สึก (1 วินาทีเท่ากันสำหรับคน). แต่โจรที่ต้องลอง 6.6 quadrillion ครั้ง — ความช้านี้กลายเป็นกำแพง. แทนที่จะใช้ 18 ชั่วโมง — โจรต้องใช้ ล้านปี

bcrypt (1999) — ออกแบบโดย OpenBSD — เก่าแต่ยังเก๋า#

bcrypt — สร้างปี 1999 โดย Niels Provos และ David Mazières สำหรับ OpenBSD (operating system ที่เน้น security). พื้นฐานมาจาก Blowfish cipher

จุดเด่นของ bcrypt — มี work factor (ปัจจัยกำกับความช้า) ที่ปรับได้. work factor = 12 หมายความว่า hash ใช้ 2^12 = 4,096 รอบของการคำนวณ. work factor = 14 → 16,384 รอบ → ช้ากว่าเดิม 4 เท่า. แปลภาษาคน — เมื่อ hardware เร็วขึ้นทุกปี — admin สามารถเพิ่ม work factor เพื่อให้ bcrypt ช้าพอที่จะกัน brute force ได้. ในปี 2025 work factor ที่แนะนำคือ 12-14

bcrypt ใช้กันมา 25+ ปี — ในปี 2026 ยังถือว่าใช้ได้ดี. ระบบใหญ่ๆ ทั่วโลกใช้ bcrypt — ตั้งแต่ open source frameworks (Django, Rails, Laravel) จนถึงธุรกิจ enterprise

scrypt (2009) — เพิ่ม “memory-hard” — โจรต้องลงทุน RAM แพง#

scrypt — สร้างปี 2009 โดย Colin Percival (CTO ของ Tarsnap backup service). ตัวนี้คิดต่อจาก bcrypt อีกชั้น — memory-hard

หลักการ memory-hard คือ — hash function ที่ใช้ RAM เยอะมาก. ทำไมต้องใช้ RAM เยอะ? เพราะ GPU ที่โจรใช้ทำ brute force — เก่งเรื่อง computation แต่ RAM น้อย. ถ้า hash function บังคับให้ใช้ RAM 1 GB ต่อ hash 1 ครั้ง — GPU ที่มี RAM 24 GB ก็ทำได้แค่ 24 hash พร้อมกัน. เทียบกับ SHA-256 ที่ใช้ RAM แทบไม่มี — GPU ทำพร้อมกันได้นับหมื่น. ความแตกต่างคือ scale 1,000 เท่า

ผลคือ — โจรที่อยากเร่ง brute force scrypt — ต้องซื้อ hardware ที่ RAM แพง ($$$). ส่วน user ปกติที่ login — ยังเสีย 1 วินาที. ความช้าฝั่งโจร × ล้านเท่า — แต่ความรู้สึกฝั่ง user ไม่เปลี่ยน. นี่คือ design ที่ฉลาดมาก — ทำให้ economics ของการแฮกเปลี่ยน

PBKDF2 (2000) — มาตรฐาน NIST / FIPS — ใช้ในระบบรัฐ#

PBKDF2 (Password-Based Key Derivation Function 2) — เป็นมาตรฐานของ NIST (National Institute of Standards and Technology) ของอเมริกา. FIPS-approved — แปลว่าผ่านมาตรฐานความปลอดภัยที่ระบบรัฐบาลและทหารอเมริกาใช้ได้

PBKDF2 = ใช้ hash function ที่มีอยู่แล้ว (เช่น SHA-256) → วน loop หลายแสนรอบ → ทำให้กลายเป็นช้า. ในปี 2026 NIST แนะนำ iteration count ที่ 600,000+

ข้อดีของ PBKDF2 = compliance. ถ้าบริษัทคุณต้องผ่าน FIPS หรือมาตรฐานที่อ้างถึง NIST — PBKDF2 คือ default ที่ดี. ข้อเสีย = PBKDF2 ไม่ memory-hard เหมือน scrypt — ดังนั้นกัน GPU ได้น้อยกว่า

argon2 (2015) — ปัจจุบันถือว่าดีที่สุดในวงการ — argon2id เป็นมาตรฐานใหม่#

argon2 — ชนะการแข่งขัน Password Hashing Competition (2013-2015) — การแข่งขันระดับโลกที่นักวิจัยจากทั่วโลกส่ง algorithm มาสู้กัน. มี 3 variant:

• argon2d — เน้นความเร็วและกัน GPU
• argon2i — เน้นกัน side-channel attack
• argon2id — รวมข้อดีของทั้งคู่ — เป็นตัวที่แนะนำใช้ในวงการ

argon2 ปรับได้ทั้ง 3 ปัจจัย — time cost (จำนวน iteration), memory cost (RAM ที่ใช้), parallelism (กี่ thread). ความยืดหยุ่นสูงสุดในวงการ

ในปี 2026 — OWASP (Open Web Application Security Project — องค์กรกลางของวงการ web security) แนะนำ argon2id เป็น default สำหรับโปรเจกต์ใหม่. bcrypt ยังเป็น “OK” สำหรับโปรเจกต์เก่า. PBKDF2 ยังใช้ได้ในบริบท compliance. SHA-256 / MD5 / SHA-1 = ห้ามใช้สำหรับ password เด็ดขาด

สรุปฉบับผู้บริหาร — ถาม CIO คำถามเดียวก็พอ#

ผมจะให้คุณกล่องคำตอบของ CIO ที่ผู้บริหารควรฟัง:

มุมผู้บริหาร: คำถาม stress test ที่ใช้ในประชุม IT ครั้งหน้า — “ระบบที่บริษัทเรา build เอง — ใช้ algorithm อะไร hash password? คำตอบที่อยากได้คือ bcrypt / argon2 / scrypt / PBKDF2. ถ้าคำตอบเป็น MD5 / SHA-1 / SHA-256 — ผมขอเห็นแผน migration ภายใน 30 วัน”. การ migrate ปกติทำได้แบบ rolling — คือไม่ต้อง force user ทุกคน reset password ในวันเดียว — แค่บังคับ rehash ตอน user คนนั้น login ครั้งถัดไป. ใช้เวลา 3-6 เดือนก็จะ migrate ได้ครบ. ต้นทุน — ฟรีฝั่ง software (algorithm ทั้งหมดเป็น open source). ต้นทุนหลักคือเวลา dev. ผลตอบแทน — กัน DB leak attack ระดับ catastrophic

Salt — เกลือที่โรยลงในเนื้อบดทุกชิ้น#

ปัญหาที่ Salt แก้ — ลองคิดดู ถ้าผู้ใช้ 100 คนในเว็บคุณ ตั้ง password เดียวกัน = “password123” — ทั้ง 100 คนนี้จะมี hash ใน DB เป็นค่าเดียวกัน. เพราะ hash function เป็น deterministic — input เหมือนกัน → output เหมือนกันเสมอ

โจรที่ขโมย DB มาเห็นสิ่งนี้ทันที — “อ๋อ 100 คนนี้ใช้ password เดียวกัน. ฉันเดา password นี้ออก = ได้ 100 บัญชี”

แย่กว่านั้น — โจรไม่จำเป็นต้องเดาเองด้วยซ้ำ. มีของพร้อมใช้ในวงการ — เรียกว่า Rainbow Table. Rainbow Table = database ขนาดใหญ่ที่เก็บ password ทั่วไป + hash ของมันไว้ล่วงหน้า. เช่น hash ของ “password” ใน MD5 = “5f4dcc3b…”. hash ของ “123456” ใน MD5 = “e10adc39…”. มีคนทำ Rainbow Table ของ password ยอดนิยม 1 พันล้านตัวไว้แล้ว — โหลด free จากอินเทอร์เน็ตได้

โจรที่ได้ hash ใน DB คุณ — เปิด Rainbow Table → search → match → ได้ password ทันที. ไม่ต้องลอง brute force ด้วยซ้ำ — แค่ lookup table

นี่คือปัญหาที่ Salt แก้

Salt = สตริงสุ่ม unique ต่อ user ที่ระบบใส่ก่อน hash. ทุก user มี Salt คนละค่า. ขั้นตอนคือ:

1. User สมัครสมาชิก พิมพ์ password “password123”
2. Server สุ่ม Salt = “x7Kp9mZq” (ตัวอย่างสั้นๆ — จริงๆ Salt 16-32 ตัวอักษร)
3. Server ต่อ Salt + password = “x7Kp9mZqpassword123”
4. Hash ค่านี้ → ได้ hash ตัวนึง
5. เก็บ ทั้ง hash + Salt ลง DB (Salt ไม่ secret — เก็บคู่กับ hash ปกติ)

ผลลัพธ์ — แม้ user 2 คนตั้ง password เดียวกัน — Salt ต่างกัน → hash ออกมาคนละค่า. โจรเห็นใน DB = สับสน. Rainbow Table ที่สร้างไว้ล่วงหน้า = ใช้ไม่ได้เลย เพราะ Rainbow Table ของ “password” ไม่ match กับ hash ของ “x7Kp9mZqpassword”

Salt = กัน Rainbow Table attack ทั้งหมด. ในปี 2026 — ระบบที่ไม่ใส่ Salt = ผิดวิธีรุนแรง. และข่าวดีคือ — bcrypt / argon2 / scrypt ทั้งหมด ใส่ Salt ให้อัตโนมัติเป็น built-in feature. ดังนั้นถ้าคุณใช้ algorithm พวกนี้ + ใช้ library standard → Salt มาเองครับ ไม่ต้องคิดเอง

Analogy — Salt = เกลือที่ chef โรยลงในเนื้อบดของลูกค้าทุกคน. ลูกค้าคนละจาน — เกลือคนละหยิบมือ — รสชาติคนละแบบ. ถึงโจรจะรู้สูตรเนื้อบดทั่วไป — ก็เลียนแบบของลูกค้าแต่ละคนไม่ได้

Pepper — พริกไทยที่ chef เก็บในห้องครัวลับ ไม่อยู่กับเนื้อ#

ตอนนี้คุณรู้ว่า Salt ดียังไง. คำถามถัดมา — ถ้า DB รั่ว — โจรได้ทั้ง hash + Salt — โจรยังทำอะไรได้ไหม?

คำตอบคือ — brute force ได้ครับ. ถึงจะใช้ Rainbow Table ไม่ได้ — โจรก็ลองเดา password ทีละตัว → hash + Salt → เทียบกับ DB. ถ้า password อ่อนแอ (เช่น “password123”) — แม้จะมี Salt ก็ใช้เวลาแค่วินาทีเดียวที่จะแตก. Salt ไม่ได้ช่วยเรื่องนี้ — Salt แค่กัน mass attack แบบ Rainbow Table

นี่คือที่ Pepper เข้ามา

Pepper = secret ที่ server เก็บไว้ ไม่ใส่ใน DB. มันคือสตริงเดียวกันสำหรับ user ทุกคน (ต่างจาก Salt ที่คนละค่าต่อ user). แต่ Pepper เก็บไว้ในที่ที่ DB เข้าไม่ถึง — เช่น environment variable ของ server, secret manager (AWS Secrets Manager / HashiCorp Vault), หรือ HSM (Hardware Security Module)

ขั้นตอนคือ:

1. User พิมพ์ password “password123”
2. Server ดึง Pepper จาก secret store = “GlobalPepperKey2026” (ตัวอย่าง)
3. Server สุ่ม Salt ของ user คนนี้ = “x7Kp9mZq”
4. Hash: hash(password + Salt + Pepper)
5. เก็บ hash + Salt ใน DB. ไม่เก็บ Pepper ใน DB

ผลลัพธ์ — ถ้า DB รั่ว → โจรได้ hash + Salt — แต่ไม่ได้ Pepper. ถ้าโจรลอง brute force — เขาไม่รู้ Pepper → ลองยังไงก็ไม่ match. โจรต้องแฮกทั้ง 2 ระบบพร้อมกัน (DB + secret store) ถึงจะใช้ได้ — ซึ่งเทคนิคต่างกัน + เข้าจาก vector คนละช่อง

Analogy — Pepper = พริกไทยที่ chef เก็บในห้องครัวลับ (ห้องที่แขกในร้านอาหารเข้าไม่ได้). ทุกจานที่ chef ทำ ต้องโรยพริกไทยจากห้องครัวนี้. ถึงโจรขโมยสูตรอาหาร + เกลือทั้งหมดของร้านได้ — เขาก็ทำรสชาติเหมือนต้นฉบับไม่ได้ ถ้าไม่มีพริกไทยจากห้องครัวลับ

Salt vs Pepper — ใช้ตัวไหน หรือใช้ทั้งคู่?#

ความจริงในวงการคือ — หลายบริษัทใช้ Salt อย่างเดียว ก็ OK. เพราะ:

• Salt + algorithm ดี (bcrypt/argon2) = กัน brute force ได้ในระดับที่ดีมากแล้ว
• Pepper เพิ่มความซับซ้อนในการ deploy (ต้องมี secret store แยก)
• ถ้า server ตัวเดียวเก็บทั้ง DB + Pepper — Pepper ก็แทบไม่ได้ช่วย เพราะถ้าโจรเข้า server ได้ ก็ได้ทั้งคู่

Best practice ในปี 2026:

• ✅ Salt = ใส่เสมอ (built-in กับ bcrypt/argon2 อยู่แล้ว)
• ✅ Pepper = ใส่ถ้าเก็บใน infrastructure แยก (HSM / Secret Manager) — Defense in Depth ตามที่เราคุยใน EP.04
• ❌ ไม่ใส่ Salt = ผิดมาก
• ❌ Salt แต่ hardcode ในโค้ด = ผิดเพราะไม่ unique ต่อ user

ผมขอย้ำอีกครั้งครับ — ถ้าทีม dev ของคุณใช้ bcrypt / argon2 / scrypt ผ่าน library standard — Salt มาเองแล้ว. ไม่ต้องเขียน Salt logic เอง. การพยายามเขียนเองมักจะผิด (เป็น meme ในวงการที่ว่า “don’t roll your own crypto” — อย่าเขียน crypto เอง ใช้ library ที่ผ่านการตรวจสอบเท่านั้น)

มุมผู้บริหาร: ในประชุม IT ครั้งหน้า — “ระบบเราใส่ Salt ครบทุกบัญชีไหม? ใส่ Pepper หรือไม่? Pepper เก็บที่ไหน — server เดียวกับ DB หรือแยก?”. ถ้า IT ตอบไม่ได้ = ทีมยังไม่เข้าใจ password hash ลึกพอ. ส่วน Pepper — สำหรับบริษัทขนาดกลาง: ใส่ก็ดี แต่ไม่ใส่ก็ไม่ผิดถ้า Salt + algorithm ถูก. สำหรับบริษัทที่เก็บข้อมูลละเอียดอ่อนสูง (ธนาคาร, healthcare, ระบบรัฐ) — Pepper เป็น must เพราะเป็น Defense in Depth ชั้นพิเศษ

กฎเก่า (สมัย 1990s-2000s) — ที่บริษัทไทยส่วนใหญ่ยังใช้#

ถ้าคุณทำงานในบริษัทใหญ่ของไทย — กฎ password ของระบบ HR / Email / VPN น่าจะหน้าตาประมาณนี้:

• ✓ ต้องยาวอย่างน้อย 8 ตัวอักษร
• ✓ ต้องมี uppercase + lowercase + ตัวเลข + อักขระพิเศษ
• ✓ เปลี่ยน password ทุก 30 / 60 / 90 วัน
• ✓ ห้ามใช้ password เก่าซ้ำใน 5 ครั้งล่าสุด

ผู้บริหารหลายคนเห็นกฎนี้แล้วคิดว่า “เข้มดีนะ — น่าจะปลอดภัย”

แต่ในความเป็นจริง — กฎพวกนี้ทำให้ password อ่อนแอลง ไม่ใช่แข็งแรงขึ้น

ทำไมกฎเก่าทำให้ password ห่วยลง#

ลองคิดดูครับ — กฎ “complexity (ต้องมีอักขระทุกประเภท)” + “เปลี่ยนทุก 30 วัน” บังคับให้พนักงานต้องคิด password ใหม่ทุกเดือน. มนุษย์จำของยากๆ ไม่ได้ — ดังนั้นพฤติกรรมที่เกิดจริงคือ:

• เดือนมกราคม → “Password1!”
• เดือนกุมภาพันธ์ → “Password2!”
• เดือนมีนาคม → “Password3!”
• …
• เดือนธันวาคม → “Password12!”

ผ่านกฎทุกข้อ — ตัวเลข + อักขระพิเศษ + เปลี่ยนทุกเดือน. แต่โจรเดาออกใน 5 วินาที เพราะ pattern นี้คือ pattern ที่พบมากที่สุดในวงการ

แย่กว่านั้น — เมื่อต้องเปลี่ยนบ่อยๆ พนักงานก็จะเขียน password ในกระดาษ Post-it ติด monitor / เก็บใน Excel / เก็บใน Notion ที่ไม่ secure. ความปลอดภัยทางกายภาพและทางดิจิทัลพังพร้อมกัน

สรุป — กฎ complexity + forced rotation ในยุค 1990s ออกแบบจากสมมุติฐานว่า “คนจะตั้ง password สุ่มเป๊ะ”. แต่มนุษย์ทำไม่ได้. ผลคือ — กฎออกแบบให้ปลอดภัย แต่บังคับใช้กับมนุษย์จริง = เกิดพฤติกรรมที่อ่อนแอลง

NIST SP 800-63B (2017) — กฎใหม่ที่กลับขั้ว#

ในปี 2017 — NIST ออกมาตรฐาน SP 800-63B (Digital Identity Guidelines) ที่ปฏิวัติวงการ. หลังจากดู data จาก breach ใหญ่ๆ + พฤติกรรมของผู้ใช้จริง — NIST ตัดสินใจ:

กฎใหม่:

1. Length > Complexity — เน้น ความยาว มากกว่าความซับซ้อน
   • อนุญาต passphrase ยาว (อย่างน้อยถึง 64 ตัวอักษร)
   • ไม่บังคับ uppercase / symbol / number — ให้ user เลือกเอง
2. เลิกบังคับเปลี่ยน password ตามเวลา — เปลี่ยนเฉพาะเมื่อมีหลักฐานว่ารั่ว
3. เช็ค password ใน list ที่เคย leak — ถ้าเจอใน data breach ไหนๆ → reject ทันที (ใช้ service เช่น HaveIBeenPwned API)
4. Block top 10,000 common passwords — “password123” / “qwerty” / “Bangkok2024” — บล็อกเป็น list
5. เลิกถาม secret question — เพราะส่วนใหญ่ตอบหาได้ใน social media
6. อนุญาตให้ใส่ตัวอักษรอะไรก็ได้ — รวม space, emoji 🎉, ภาษาอื่น — ยิ่งอะไรก็ได้ยิ่งดี

Length > Complexity — ทำไมยาว 16 ตัวง่ายๆ ดีกว่าซับซ้อน 8 ตัว#

เรื่องนี้สำคัญมาก ขอ unpack ครับ

ในทาง mathematical — ความแข็งแรงของ password คำนวณจาก entropy (ปริมาณข้อมูลสุ่ม). entropy = log2(จำนวนความเป็นไปได้)

• Password 8 ตัวอักษร — ใช้ตัวอักษร 95 ตัว (a-z, A-Z, 0-9, อักขระพิเศษ) → 95^8 = 6.6 quadrillion ความเป็นไปได้ → entropy ~52 bits
• Passphrase 16 ตัวอักษร ตัวพิมพ์เล็กล้วน — ใช้ 26 ตัว → 26^16 = 43 quintillion → entropy ~75 bits
• Passphrase 4 คำสุ่ม เช่น “correct horse battery staple” — ใช้คำ 2,048 คำในพจนานุกรม → 2048^4 = 17 trillion → entropy ~44 bits (ในกรณีคำเป็นพจนานุกรมแน่นอน — ในชีวิตจริงสูงกว่า)

ตัวเลขเหล่านี้แปลภาษาคนคือ — password 16 ตัวพิมพ์เล็กล้วน แข็งแรงกว่า password 8 ตัวที่ผสมทุกประเภท ประมาณ 8 ล้านเท่า

และที่สำคัญที่สุดในการใช้งานจริง — passphrase ยาวจำง่ายกว่า. “กินข้าวเย็นกับยายที่บ้านสวนวันอาทิตย์” 28 ตัวอักษร — คุณจำได้ครั้งเดียวก็ติดหู. “P@ssw0rd1!” 10 ตัวอักษรซับซ้อน — คุณจำผิดตัวก็ login ไม่ได้

นี่คือเหตุที่ xkcd comic ที่โด่งดัง ที่ชื่อ “Password Strength” — ตั้งแต่ปี 2011 — ใช้ passphrase “correct horse battery staple” เป็นตัวอย่าง. 28 ตัวอักษรง่ายๆ — แข็งแรงกว่า password 11 ตัวอักษรซับซ้อนของ admin ทั่วไป ล้านเท่า

บริษัทไทยกับการ migrate ไป NIST 2017#

ในปี 2026 — มีบริษัทไทยจำนวนน้อยมากที่ migrate กฎ password ไปตาม NIST. ส่วนใหญ่ยังบังคับ “8 ตัว + uppercase + symbol + เปลี่ยนทุก 90 วัน” เพราะ:

• กฎเดิมอยู่ใน policy บริษัทมา 15+ ปี
• ผู้บริหารคิดว่า “เข้มไว้ดี” — ไม่รู้ว่ามันทำให้พฤติกรรมแย่ลง
• IT auditor หลายคนยังใช้ checklist เก่า — ถ้าไม่บังคับ rotation = ไม่ผ่าน audit (audit ที่ใช้ checklist ปี 2010)

ทางออก — ผู้บริหารต้องเป็นคน initiate การ update policy. เริ่มจาก:

1. Update password policy ของบริษัท — เน้น length (12+ ตัวอักษร) แทน complexity. เลิกบังคับ rotation. อนุญาต passphrase
2. Integrate กับ HaveIBeenPwned API — ตอน user ตั้ง password ใหม่ → ระบบเช็คอัตโนมัติว่าเคยอยู่ใน leak ไหม → ถ้าใช่ → reject
3. Educate พนักงาน — สอนเรื่อง passphrase แทน complex password. สอนเรื่อง Password Manager (หัวข้อ 6)
4. บังคับ MFA — เพราะถ้ามี MFA password ตัวเดียวพังก็ไม่เปิดทุกประตู (จาก EP.11)

มุมผู้บริหาร: ถามทีม HR + IT ในประชุม Q1 — “Password policy ของบริษัทเรา update ครั้งล่าสุดเมื่อไหร่? ตรงตาม NIST SP 800-63B (2017) หรือยัง?”. ถ้าตอบ “อัปเดตปี 2015 ใช้กฎ complexity + rotation 90 วัน” — เริ่มกระบวนการ update ทันที. ผลตอบแทน — พนักงานจะตั้ง password ที่แข็งแรงขึ้นจริง + ใช้ Password Manager ได้ + ลดการเขียน password ในกระดาษ Post-it ที่ติด monitor

Credential Stuffing — เทคนิคที่ใช้ password ของเว็บนึง ลองเว็บอื่น#

Credential Stuffing = เทคนิคที่โจรเอา username + password ที่ leak จากเว็บ A — ไปลอง login เว็บ B / C / D / E ทุกเว็บในโลก. ทำไมได้ผล? เพราะ คนส่วนใหญ่ใช้ password เดียวกันใน 10-20 เว็บ

หลักการง่ายๆ — ทุกวันในโลก มี data breach เกิดขึ้น. ใน 5 ปีที่ผ่านมา breach ใหญ่ๆ ที่ได้ข่าว — Yahoo (3 พันล้านบัญชี), LinkedIn, Adobe, Dropbox, MyFitnessPal, Marriott — รวมๆ แล้ว credential ที่ leak ในโลก = 10+ พันล้านชุด. ทั้งหมดนี้ขายในตลาดมืดราคา $5-$50 ต่อ 1 ล้านชุด. โจรซื้อมา → automate การลอง login เว็บอื่นๆ ทั่วโลก

อัตราความสำเร็จของ Credential Stuffing ในปี 2025 = ประมาณ 0.1-2% ของ credential ที่ลอง. ฟังดูน้อยใช่ไหม? — ลองคิดดู ถ้าโจรลอง 10 ล้าน credential กับเว็บคุณ — 0.1% = 10,000 บัญชีลูกค้าที่โจรเข้าได้. ทุกบัญชี = ความเสียหาย

ทำไมป้องกันยาก — เพราะจากมุมระบบ — login ของโจรกับ login ของลูกค้าจริง หน้าตาเหมือนกัน. username + password ที่ถูก. ระบบไม่มีทางรู้ว่าใครเป็นเจ้าของบัญชีจริง. ทางป้องกันคือ — MFA (จาก EP.11) + เช็ค password กับ list ที่ leak (HaveIBeenPwned) + rate limiting (จำกัดจำนวนการลอง login ต่อนาที) + detect anomaly (ลูกค้าปกติ login จากไทย — login จากรัสเซียครั้งแรก = สงสัย)

Colonial Pipeline 2021 — ท่อน้ำมันครึ่งฝั่งตะวันออกของอเมริกาหยุด 6 วัน เพราะ password 1 ตัว#

เคสนี้คือเคสที่ผู้บริหารทั่วโลกควรอ่าน เพราะมันแสดงว่า password 1 ตัวสามารถหยุดเศรษฐกิจระดับประเทศได้

Colonial Pipeline = บริษัท pipeline ส่งน้ำมันที่ใหญ่ที่สุดของอเมริกา. ส่งน้ำมัน 45% ของฝั่งตะวันออกของอเมริกา — จาก Texas ไปถึง New York. ระยะทาง 5,500 ไมล์ ส่งน้ำมัน 100 ล้านแกลลอนต่อวัน

วันที่ 7 พฤษภาคม 2021 — Colonial โดน ransomware attack จากกลุ่ม DarkSide (กลุ่ม Russian cybercrime). บริษัทต้องหยุดการดำเนินงานทั้งหมด 6 วัน. ผลกระทบ:

• ปั๊มน้ำมัน 11,000+ แห่งทางฝั่งตะวันออกของอเมริกา ขาดน้ำมัน — มีภาพคน queue ขับรถเป็นกิโลเพื่อเติมน้ำมัน
• ราคาน้ำมันในตลาดอเมริกาสูงสุดในรอบ 6 ปี
• รัฐบาล Biden ประกาศ state of emergency
• Colonial จ่าย ransom $4.4 ล้าน ใน Bitcoin (FBI ภายหลังตามคืนได้บางส่วน)

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

หลังการสอบสวน — FBI พบว่าโจรเข้าระบบผ่าน VPN account เก่าตัวเดียวที่ไม่มี MFA. account นี้:

• เป็น account VPN ของพนักงานคนหนึ่งที่เคยทำงานที่ Colonial
• บริษัทไม่ได้ disable account ตอนพนักงานคนนี้ออก (= orphan account จาก EP.10)
• password ของ account นี้ leak อยู่ใน dark web มาเป็นปี — อยู่ใน data breach ของเว็บอื่นที่พนักงานคนนี้เคยใช้ password เดียวกัน
• ไม่มี MFA — มี password อย่างเดียว

โจร DarkSide ทำ Credential Stuffing — เจอ VPN ของ Colonial — ลอง — สำเร็จในครั้งแรก. จากจุดนั้น โจรเข้า internal network → install ransomware → encrypt ระบบ → เรียก ransom

บทเรียน:

1. Orphan account = ภัยที่บริษัทไม่รู้ว่ามี (EP.10 ผมเล่าเรื่องนี้แล้ว)
2. Password reuse = ทำให้ Credential Stuffing เป็นไปได้
3. ไม่มี MFA = password ตัวเดียวพัง = ระบบเปิดทันที
4. Critical infrastructure ของประเทศใหญ่ — โดน hack ได้จาก password 1 ตัว

ผมอยากให้ผู้บริหารทุกคนจำเคสนี้ครับ — ความเสียหายระดับชาติของอเมริกา — เกิดจาก control พื้นฐาน 3 ข้อที่บริษัทไม่ได้ทำ — MFA, lifecycle management, password hygiene. ไม่ใช่ zero-day exploit ล้ำสมัย. ไม่ใช่ AI ที่แฮกเก่ง. แค่ basic security ที่ตกหล่น

HaveIBeenPwned — เว็บฟรีที่ทุกคนควรเช็ค#

ก่อนเข้าหัวข้อสุดท้าย ผมอยากแนะนำเครื่องมือฟรีที่ผมแนะนำกับทุกคนรอบตัวครับ — HaveIBeenPwned (https://haveibeenpwned.com)

HaveIBeenPwned = service ฟรีที่สร้างโดย Troy Hunt (security expert ชาวออสเตรเลีย). มันคือ database รวม credential ทั้งหมดที่เคย leak ในโลก — ปัจจุบัน 12+ พันล้านชุด

วิธีใช้:

1. ไปที่ haveibeenpwned.com
2. ใส่ email ของคุณ
3. ระบบบอกว่า email คุณเคยอยู่ใน data breach กี่ตัว + เคสไหนบ้าง

ลองนึกภาพการเช็คทั่วไป — email ทั่วไปของคนที่ใช้ internet มา 10+ ปี มักจะเจอผลออกมาราว ๆ 5-10 breach. breach คลาสสิคในวงการคือ LinkedIn ปี 2012 / Adobe ปี 2013 / Dropbox ปี 2012 / Yahoo 2013-14 / etc. แปลภาษาคน — password ที่คุณเคยตั้งใน 5-10 เว็บนั้น อยู่ในตลาดมืดมาเป็น 10+ ปี. ถ้าคุณใช้ password เดียวกันในเว็บอื่น — โจรลอง credential stuffing เข้าได้ทันที. นี่คือเหตุที่ Password Manager + unique password ต่อเว็บคือทางออกเดียว

สำหรับผู้บริหาร — integrate HaveIBeenPwned API เข้าระบบบริษัท. ตอน user ตั้ง password ใหม่ → ระบบเช็คอัตโนมัติว่า password นั้นเคย leak ไหม → ถ้าเคย → reject ให้ตั้งใหม่. API ฟรีสำหรับใช้งานพื้นฐาน. ทำได้ภายใน 1 sprint ของ dev team

Password Manager คืออะไร — และทำไมคนทำงาน knowledge worker ต้องมี#

Password Manager = software ที่ทำ 3 อย่าง:

1. Generate password ยาวสุ่มเป๊ะให้คุณ (เช่น “Kx9$mPq2!nRv7zL@”) — ทุกเว็บคนละค่า
2. Store password ทั้งหมดในที่เดียว — encrypt ด้วย master password ของคุณ
3. Auto-fill ตอนคุณ login — เปิดเว็บ → กดปุ่ม → password กรอกอัตโนมัติ

แปลภาษาคนคือ — คุณจำแค่ master password ตัวเดียว. ที่เหลือ Password Manager จัดการให้หมด

ตัวที่ใช้กันในวงการ:

• 1Password — เก่งสุดในตลาดสำหรับ usability — paid ($3-5/เดือน)
• Bitwarden — open source — ฟรีสำหรับ personal — paid ถูกสำหรับ team
• KeePass / KeePassXC — open source — ฟรี — เก็บใน local file (ไม่ cloud) — สำหรับคนที่ paranoid เรื่อง cloud
• Dashlane / NordPass / Proton Pass — ตัวเลือกอื่นในตลาด

ทุกตัวมี features หลัก:

• Generate strong password (16-30 ตัวอักษรสุ่ม)
• Sync ข้าม device (มือถือ + laptop + browser)
• Auto-fill ในเว็บและแอป
• Share password กับทีมแบบ secure (สำคัญสำหรับ password ของ service ที่ทั้งทีมต้องใช้)
• Audit feature — เตือนถ้า password ของคุณเคย leak / ใช้ซ้ำ / อ่อนแอ

Master Password — กุญแจตัวเดียวที่ต้องจำให้แน่น#

ผมต้องเตือนข้อนึงครับ — Password Manager มีจุดอ่อน 1 จุด — master password. ถ้า master password คุณรั่ว → โจรเข้าได้ทั้งหมด

ทางออก:

1. Master password ต้องยาว + unique — passphrase 5-7 คำที่ไม่เกี่ยวกับคุณ (“ปลากระพงสีม่วงเดินทางสายเหนือกลางคืน”) — 30+ ตัวอักษร — จำได้ในใจ
2. Enable MFA บน Password Manager — แม้แฮกเกอร์รู้ master password ก็ต้องผ่าน MFA อีกชั้น
3. อย่าใช้ master password ใน เว็บอื่น — เด็ดขาด

กับดักที่ผู้บริหารต้องระวัง — เก็บ password ผิดที่#

pattern คลาสสิคของวงการที่ขึ้นข่าวบ่อย — พนักงานเก็บ password ของระบบสำคัญใน:

• Excel / Google Sheets ที่ไม่ encrypt
• Notion / OneNote / Evernote — note app ทั่วไป
• Word document ที่ตั้งชื่อ “passwords.docx”
• กระดาษ Post-it ติด monitor
• Email draft ของตัวเอง
• Chat ใน Line / WhatsApp / Slack ของตัวเอง

ทุกอย่างพวกนี้ = เก็บกุญแจในกล่องไม่ล็อก. ใครเข้า device คุณได้ = เห็นทุก password. และที่แย่ที่สุดคือ — Excel / Notion ของบริษัทมักจะ sync cloud อัตโนมัติ → ถ้า account cloud โดน hack = password ทั้งหมดรั่ว

ทางแก้สั้นๆ — บริษัทจัด Password Manager Business edition ให้พนักงานทุกคน. ราคา 1Password Business / Bitwarden Teams = ประมาณ $5-8 ต่อพนักงานต่อเดือน. ลงทุน 100,000-200,000 บาท/ปี สำหรับบริษัท 100 คน. ผล — ลด credential stuffing attack ลง 90%+ + ลดการเก็บ password ใน Excel ที่ insecure

Password Manager ในบริบทบริษัทไทย — สถานะปี 2026#

pattern คลาสสิคของวงการที่ขึ้นข่าวบ่อยและที่ผมเห็นจากการอ่านรายงาน — ในปี 2026 ที่ผมเขียน บริษัทไทยขนาดกลาง-ใหญ่ ยังไม่ได้ deploy Password Manager กันเป็น norm. ส่วนใหญ่:

• บริษัทใหญ่ระดับ enterprise — มี SSO (Single Sign-On จาก Azure AD / Okta) → ลด password ที่ต้องจำ. แต่ระบบที่ไม่อยู่ใน SSO — พนักงานก็ยังเก็บใน Excel
• บริษัทกลาง 100-500 คน — ส่วนใหญ่ไม่มี SSO + ไม่มี Password Manager — เก็บใน Excel เป็น norm
• บริษัทเล็ก SME — เก็บใน Line / Notion / กระดาษ

ทางออกระดับ org สำหรับผู้บริหารบริษัทไทย:

1. Tier 1 — ลงทุนได้ — Password Manager Business edition (1Password / Bitwarden) ทุกพนักงาน → +SSO สำหรับระบบหลัก
2. Tier 2 — งบจำกัด — Bitwarden Teams (ถูกกว่า 1Password มาก) — หรือ KeePass + shared vault ใน secure file share
3. Tier 3 — ไม่มีงบ — บังคับใช้ Browser Password Manager (Chrome / Firefox / Safari ทุกตัวมี built-in ฟรี — encrypt อยู่แล้ว) — ไม่เก่งเท่า dedicated tool แต่ดีกว่า Excel หลายเท่า

มุมผู้บริหาร: คำถาม stress test ของหัวข้อนี้ — “พนักงานบริษัทเรา เก็บ password ของระบบสำคัญที่ไหน? ทีม IT เคย audit เรื่องนี้ไหม?”. ถ้าคำตอบคือ “ไม่เคย audit” — ทำ survey ภายในไตรมาสนี้. ถ้าคำตอบรวมแล้วเจอ “Excel / Notion / Line / Post-it” จำนวนมาก = สัญญาณว่าต้อง deploy Password Manager. การลงทุน — 100,000-200,000 บาท/ปี สำหรับ 100 คน. ROI — ลด credential stuffing + ลดความเสี่ยงพนักงานเก่าเอา password ไป + ลดเวลา IT helpdesk ที่ต้อง reset password ให้พนักงาน

สิ่งที่ผู้นำต้องจำ — 2 ข้อ#

ข้อแรก — ห้ามเก็บ password เป็น Plain Text. ถามทีม IT: “เราใช้ algorithm อะไร hash password?”

นี่คือคำถามที่ผู้บริหารควรถามทีม IT ในประชุมต่อไป — “ระบบทั้งหมดของบริษัทเราที่เก็บ password — ใช้ algorithm อะไร hash?”. คำตอบที่ดีที่อยากได้ — bcrypt / argon2 / scrypt / PBKDF2 + ใส่ Salt อัตโนมัติ. คำตอบที่แดงทันที — Plain Text / encryption ที่ย้อนได้ / MD5 / SHA-1 / SHA-256

ถ้าเจอคำตอบที่แดง — ต้องวางแผน migration ทันที. ขั้นตอน:

1. Audit — list ระบบทั้งหมดที่เก็บ password ของลูกค้า/พนักงาน
2. Identify — ระบบไหนยังใช้ algorithm ผิด
3. Plan migration — สำหรับแต่ละระบบ ทำได้ 2 วิธี:
   • Re-hash ตอน user login ครั้งถัดไป — ที่ user พิมพ์ password → ระบบมี plaintext ชั่วคราว → hash ใหม่ด้วย algorithm ที่ถูก → เก็บแทน hash เก่า. ใช้เวลา 3-6 เดือน จะ migrate ครบ
   • Force password reset — บังคับ user ทุกคน reset password ครั้งถัดไป → ระบบ hash ด้วย algorithm ใหม่ทันที. เร็วกว่าแต่กระทบ user
4. Verify — หลัง migrate ครบ → audit ครั้งสุดท้าย → ลบ hash เก่าทั้งหมด

การลงทุน — ฟรีฝั่ง software (algorithm ทุกตัวเป็น open source). ต้นทุนหลักคือเวลาของ dev team. ROI = กัน DB leak attack ระดับ catastrophic — เพราะ DB leak ใน 2026 ไม่ใช่คำถาม “ถ้า” แต่เป็น “เมื่อไหร่”

ข้อสอง — Deploy Password Manager Business edition ให้ทุกพนักงาน — ลด credential stuffing ลง 90%+

ข้อนี้คือ control ที่ ROI สูงที่สุดในระดับ behavioral ของ password security. การลงทุน — 1Password Business หรือ Bitwarden Teams = ประมาณ 100,000-200,000 บาท/ปี สำหรับ 100 พนักงาน. ผลตอบแทน:

• พนักงานเลิกใช้ password ซ้ำในทุกเว็บ → กัน credential stuffing
• พนักงานเลิกเก็บ password ใน Excel / Notion / Line → กัน insider leak + ลด attack surface
• พนักงานเลิกใช้ password อ่อนแอ → Password Manager generate ให้ 16-30 ตัวอักษรสุ่มเป๊ะ
• ลด IT helpdesk ticket เรื่อง reset password 50%+
• เพิ่ม audit trail ของการเข้าถึง password ของระบบสำคัญ
• เตือนพนักงานอัตโนมัติเมื่อ password ที่ใช้อยู่ leak ใน breach

ขั้นตอน roll out ภายใน 6-12 เดือน:

1. Month 1-2 — เลือก vendor (1Password / Bitwarden / KeePass) + pilot กับ IT team + admin
2. Month 3-4 — ขยายไปกลุ่ม executive + finance (เพราะคนกลุ่มนี้เก็บ password ของระบบ critical เยอะที่สุด)
3. Month 5-8 — roll out ทุกพนักงาน + training
4. Month 9-12 — track adoption rate. เป้าหมาย 90%+ ของพนักงาน active ใช้

ในวงการ security เรามักพูดว่า — “Security is a process, not a product.” Password Manager คือ exception ของกฎนี้ — มันเป็น product ที่ deploy ครั้งเดียวแล้ว behavioral security ของทั้งบริษัทยกระดับขึ้นหลายชั้น