รหัสผ่านรั่วรับมืออย่างไร? เพิ่ม“ยืนยันตัวตนหลายชั้น”ให้ระบบเดิม ไม่ต้องรื้อใหม่

ปัญหาข้อมูลส่วนบุคคลรั่วไหลยังเป็นความเสี่ยงสำคัญขององค์กรในยุคดิจิทัล สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) เปิดสถิติการตรวจสอบเชิงรุกและเฝ้าระวังการละเมิดข้อมูลส่วนบุคคล ภายใต้ศูนย์ PDPC Eagle Eye ช่วง 6 เดือน ตั้งแต่เดือนตุลาคม 2568 – มีนาคม 2569 พบมีการตรวจสอบรวมกว่า 590,001 URL

สคส.ตรวจพบความเสี่ยงข้อมูลส่วนบุคคลรั่วไหล 205 เรื่อง และดำเนินการแก้ไขได้ทั้งหมด โดยองค์กรปกครองส่วนท้องถิ่นพบมากที่สุด 159 เรื่อง รองลงมาคือหน่วยงานภาครัฐ 31 เรื่อง และภาคการศึกษา 15 เรื่อง

ตัวเลขดังกล่าวสะท้อนว่า การดูแลระบบดิจิทัลและข้อมูลประชาชนไม่ควรรอให้เกิดเหตุเสียก่อน โดยหนึ่งในจุดสำคัญที่องค์กรต้องให้ความสนใจคือ “ระบบยืนยันตัวตน” โดยเฉพาะเว็บไซต์ ระบบหลังบ้าน และระบบเก่าที่ยังใช้เพียง Username และ Password ในการเข้าสู่ระบบ

 

ดร.มนต์ศักดิ์ โซ่เจริญธรรม ที่ปรึกษาเลขาธิการคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ ให้คำแนะนำว่า หนึ่งในมาตรการที่สามารถช่วยลดความเสี่ยงจากกรณีรหัสผ่านรั่วได้อย่างมีนัยสำคัญ คือการเพิ่มการยืนยันตัวตนแบบหลายชั้น  MFA หรือ Multi-Factor Authentication เพื่อให้รหัสผ่านไม่ใช่กุญแจเพียงดอกเดียวที่ใช้เข้าสู่ระบบสำคัญขององค์กร

รหัสผ่านรั่ว ไม่ได้เสียหายแค่บัญชีเดียว

ดร.มนต์ศักดิ์ อธิบายว่า สำหรับหน่วยงานหรือองค์กร “รหัสผ่านรั่ว” ไม่ได้หมายความเพียงบัญชีผู้ใช้งานหนึ่งบัญชีถูกขโมยเท่านั้น

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

โดยเฉพาะระบบที่ถูกพัฒนามานาน ใช้เทคโนโลยีหรือ Library รุ่นเก่า และยังอาศัยการยืนยันตัวตนเพียง Username + Password ชั้นเดียว ความเสียหายจากบัญชีหนึ่งบัญชีจึงอาจขยายไปสู่ระบบส่วนอื่นขององค์กรได้

 

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

MFA คืออะไร ทำไมระบบเก่าก็ควรมี

ดร.มนต์ศักดิ์ ระบุว่า สำหรับระบบเดิมหรือ Legacy System วิธีหนึ่งที่สามารถพิจารณาได้คือ TOTP หรือ Time-based One-Time Password ซึ่งเป็นรหัส OTP ที่เปลี่ยนไปตามเวลา และสามารถทำงานร่วมกับแอป Authenticator ที่รองรับมาตรฐาน TOTP

จากเดิมผู้ใช้งานเข้าสู่ระบบด้วย

Username + Password → เข้าใช้งาน

เมื่อเพิ่ม MFA จะกลายเป็น

Username + Password → OTP → เข้าใช้งาน

ข้อดีคือ ต่อให้ผู้โจมตีรู้ Username และ Password ก็ยังต้องผ่านการตรวจสอบ OTP อีกขั้นหนึ่งก่อนที่จะสามารถเข้าใช้งานระบบได้

TOTP ทำงานอย่างไร

ดร.มนต์ศักดิ์ อธิบายหลักการว่า เมื่อผู้ใช้งานเปิด MFA ระบบจะสร้าง Secret Key เฉพาะสำหรับบัญชีนั้น และนำไปแสดงในรูปแบบ QR Code เพื่อให้ผู้ใช้สแกนด้วยแอป Authenticator บนโทรศัพท์

หลังจากนั้น ทั้งเว็บไซต์และแอป Authenticator จะมี Secret Key ชุดเดียวกัน และนำ Secret Key รวมกับเวลาปัจจุบันไปคำนวณด้วยอัลกอริทึมเดียวกัน จึงได้ OTP ที่ตรงกัน

ด้วยเหตุนี้ เว็บไซต์จึงไม่จำเป็นต้องรู้ว่า OTP มาจากโทรศัพท์เครื่องใด และไม่จำเป็นต้องเก็บหมายเลขโทรศัพท์ IMEI หรือ Device ID เพื่อให้ระบบ TOTP ทำงาน

สิ่งที่สำคัญกว่าคือ การปกป้อง Secret Key ไม่ให้รั่วไหล เพราะหากผู้โจมตีได้ทั้ง Password และ MFA Secret ก็อาจสร้าง OTP ได้เช่นเดียวกับโทรศัพท์ของผู้ใช้งาน

ระบบเก่าเพิ่ม MFA ได้ ไม่จำเป็นต้องรื้อใหม่ทั้งหมด

คำถามสำคัญสำหรับหลายองค์กรคือ หากเว็บไซต์หรือระบบหลังบ้านใช้งานมานาน จะต้องสร้างระบบใหม่ทั้งหมดเพื่อเพิ่ม MFA หรือไม่

ดร.มนต์ศักดิ์ ระบุว่า ในหลายกรณีไม่จำเป็น โดยสามารถพิจารณาได้อย่างน้อย 2 แนวทาง

1. เพิ่ม MFA เข้าไปใน Application โดยตรง

หากยังสามารถแก้ไข Source Code ของระบบเดิมได้ วิธีตรงที่สุดคือเพิ่มขั้นตอนตรวจสอบ OTP หลังจากระบบตรวจสอบ Username และ Password ผ่านแล้ว

จากเดิม

Password ถูกต้อง → สร้าง Session

เปลี่ยนเป็น

Password ถูกต้อง → ตรวจสอบ MFA → สร้าง Session

ระบบอาจเพิ่มข้อมูลเกี่ยวกับ MFA เข้าไปในบัญชีผู้ใช้งาน เช่น Secret Key และสถานะว่าบัญชีนั้นเปิด MFA แล้วหรือไม่

อย่างไรก็ตาม ดร.มนต์ศักดิ์ แนะนำว่า ก่อนนำ Library หรือเครื่องมือ MFA มาใช้ ต้องตรวจสอบก่อนว่าเว็บไซต์พัฒนาด้วยเทคโนโลยีใด เช่น PHP, ASP.NET, ASP Classic, Java, Python หรือ Node.js รวมถึงตรวจสอบ Runtime, Framework และ Library ที่ระบบใช้งานอยู่

เหตุผลคือระบบเก่าอาจไม่รองรับ Library รุ่นใหม่ ขณะที่ Library เก่าบางตัวอาจหยุดพัฒนาแล้วหรือมีข้อจำกัดด้านความปลอดภัย จึงไม่ควรเลือกใช้เพียงเพราะสามารถติดตั้งเข้ากับระบบเดิมได้

2. ใช้ Authentication Gateway อยู่ด้านหน้าระบบ

ในกรณีที่ระบบเก่ามาก ไม่สามารถแก้ไข Source Code ได้ง่าย หรือไม่มีผู้ดูแลที่เข้าใจโครงสร้างระบบเดิม ดร.มนต์ศักดิ์ เสนออีกทางเลือก คือการวาง Authentication หรือ Identity Gateway ไว้ด้านหน้าเว็บไซต์เดิม

โครงสร้างจะเปลี่ยนเป็น

Internet / User → MFA / Identity Gateway → เว็บไซต์เดิม

วิธีนี้ช่วยเพิ่มชั้น Authentication โดยไม่จำเป็นต้องแก้ Business Logic ภายในเว็บไซต์เดิมมากนัก

แต่ไม่ได้หมายความว่าสามารถติดตั้งแล้วใช้งานได้ทันที เพราะองค์กรยังต้องออกแบบเรื่อง Network Architecture, Reverse Proxy, DNS, TLS, Session, Header Trust, Access Control, Logging รวมถึงตรวจสอบเส้นทางที่อาจถูกใช้เพื่อ Bypass ระบบยืนยันตัวตน

ก่อนติด MFA อย่าเพิ่งเริ่มจากแก้หน้า Login

อีกหนึ่งคำแนะนำสำคัญจาก ดร.มนต์ศักดิ์ คือ อย่าเพิ่งเริ่มจากการแก้หน้า Login ทันที แต่ควรสำรวจระบบเดิมให้ชัดเจนก่อน

เรื่องแรกคือ ต้องรู้ว่าเว็บไซต์พัฒนาด้วยเทคโนโลยีอะไร ใช้ Runtime, Framework และ Library เวอร์ชันใด เพราะข้อมูลเหล่านี้จะเป็นตัวกำหนดว่าเครื่องมือ MFA แบบใดเหมาะสมกับระบบ

เรื่องที่สองคือ ต้องสำรอง Source Code, Database, Configuration และ Environment ที่จำเป็น เพื่อให้สามารถย้อนกลับไปยังระบบเดิมได้ หากการปรับปรุงเกิดปัญหา

เรื่องที่สามคือ ต้องหา Authentication Flow ให้เจอว่า ส่วนใดของระบบรับ Username และ Password ส่วนใดตรวจสอบสิทธิ์ ส่วนใดสร้าง Session และระบบ Redirect ผู้ใช้งานอย่างไรหลัง Login สำเร็จ

การเข้าใจโครงสร้างเหล่านี้ก่อน จะช่วยลดความเสี่ยงที่การเพิ่มระบบรักษาความปลอดภัยใหม่ กลับสร้างปัญหาให้กับระบบเดิม

ใช้ TOTP ต้องระวังเรื่อง “เวลา”

เนื่องจาก TOTP ใช้เวลาปัจจุบันเป็นส่วนหนึ่งของการคำนวณ OTP ดังนั้นเวลาของเซิร์ฟเวอร์และโทรศัพท์ของผู้ใช้งานต้องไม่คลาดเคลื่อนกันมากเกินไป

ดร.มนต์ศักดิ์ ระบุว่า ปัญหาเรื่อง Clock Skew เป็นหนึ่งในสาเหตุที่อาจทำให้ผู้ใช้งานกรอก OTP ถูกต้องตามที่เห็นบนโทรศัพท์ แต่ระบบกลับปฏิเสธ

แนวทางคือ เซิร์ฟเวอร์ควร Sync เวลากับ NTP อย่างสม่ำเสมอ ตรวจสอบ Timezone ให้ถูกต้อง และกำหนด Time Window ให้ยอมรับความคลาดเคลื่อนเพียงเล็กน้อย โดยทั่วไปประมาณ ±1 ช่วงเวลา หรือราว ±30 วินาที

ไม่ควรแก้ปัญหาด้วยการขยายช่วงเวลาให้กว้างเกินไปเพียงเพื่อให้ผู้ใช้ Login ได้ง่ายขึ้น เพราะจะทำให้ OTP สามารถใช้งานได้นานขึ้น และลดระดับความปลอดภัยของระบบ

เริ่มใช้ MFA จากบัญชีสิทธิ์สูงก่อน

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

ไม่ว่าจะเป็น Administrator, System Administrator, Web Administrator, Database Administrator ตลอดจนบัญชีที่สามารถเข้าถึงข้อมูลสำคัญ

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

จุดอ่อนที่หลายองค์กรมองข้าม “Reset MFA”

การเพิ่ม MFA เพียงอย่างเดียวยังไม่เพียงพอ หากกระบวนการกู้คืนบัญชีถูกออกแบบไว้อย่างหละหลวม

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

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

องค์กรจึงควรมีกระบวนการ Recovery ที่รัดกุม อาจใช้ Backup Codes แบบครั้งเดียว หรือมีกระบวนการยืนยันตัวตนผ่านผู้ดูแลตามนโยบาย พร้อมกำหนดผู้ที่มีสิทธิ์ Reset และบันทึกเหตุการณ์ทุกครั้ง

MFA Secret ต้องได้รับการป้องกัน

ดร.มนต์ศักดิ์ ยังชี้ว่า อีกเรื่องที่มักถูกมองข้ามคือการจัดเก็บ MFA Secret

บางระบบอาจเพิ่มคอลัมน์ mfa_secret ลงในฐานข้อมูลแล้วจัดเก็บค่าไว้โดยตรง แต่ Secret ดังกล่าวถือเป็นข้อมูลสำคัญ เพราะหากผู้โจมตีได้ Secret ไปพร้อมกับ Password ก็อาจนำไปสร้าง OTP ได้

องค์กรจึงควรพิจารณามาตรการ เช่น การ Encryption at Rest จำกัดสิทธิ์เข้าถึงฐานข้อมูล แยก Encryption Key ออกจาก Database ป้องกัน Secret ไม่ให้ปรากฏใน Log และไม่แสดง QR Code ซ้ำโดยไม่จำเป็น

มี MFA แล้ว อย่าทิ้ง Password Policy

ดร.มนต์ศักดิ์ ย้ำว่า MFA ไม่ควรถูกมองว่าเป็นมาตรการเดียวที่สามารถแก้ปัญหา Authentication ได้ทั้งหมด

องค์กรยังต้องดูแล Password Policy ควบคู่กัน เช่น สนับสนุนการใช้รหัสผ่านหรือ Passphrase ที่มีความยาวเพียงพอ ป้องกันการใช้รหัสผ่านที่อ่อนแอ และไม่ใช้รหัสผ่านที่ทราบว่ารั่วไหลแล้ว

นอกจากนี้ควรเปิด Logging สำหรับเหตุการณ์สำคัญ เช่น Login สำเร็จ Login ล้มเหลว OTP ผิด การเปิด MFA การ Reset MFA การใช้ Backup Code และการ Reset โดย Administrator เพื่อให้สามารถตรวจสอบย้อนหลังและรองรับ Incident Response ได้

TOTP ไม่ได้ป้องกัน Phishing 100%

แม้ TOTP จะช่วยลดความเสี่ยงจากกรณี Password รั่วได้มาก แต่ไม่ได้หมายความว่าจะป้องกัน Phishing ได้ทุกกรณี

ดร.มนต์ศักดิ์ อธิบายว่า ผู้โจมตีบางรูปแบบสามารถทำ Real-time Phishing โดยสร้างเว็บไซต์ปลอม แล้วหลอกให้ผู้ใช้งานกรอกทั้ง Password และ OTP ก่อนนำข้อมูลไปใช้กับระบบจริงทันที

ดังนั้น สำหรับระบบที่มีความสำคัญสูง องค์กรควรพิจารณา MFA ที่มีความสามารถต้านทาน Phishing ได้มากขึ้น เช่น FIDO2, WebAuthn, Passkeys หรือ Hardware Security Key ตามระดับความเสี่ยงและความเหมาะสมของระบบ

5 ขั้นตอนเร่งด่วน เพิ่ม MFA ให้ระบบองค์กร

สำหรับหน่วยงานที่ยังมีเว็บไซต์หรือระบบหลังบ้านใช้ Username และ Password เพียงอย่างเดียว ดร.มนต์ศักดิ์ สรุปแนวทางเริ่มต้นไว้ 5 ขั้นตอน ได้แก่

1. สำรวจระบบ ตรวจสอบว่าระบบใดเปิดให้เข้าถึงจาก Internet และบัญชีใดมีสิทธิ์ระดับสูง
2. จัดลำดับความสำคัญ เริ่มจาก Administrator และระบบที่จัดเก็บหรือเข้าถึงข้อมูลสำคัญ
3. เลือกวิธีเพิ่ม MFA พิจารณาว่าควรแก้ Application โดยตรง หรือใช้ Identity Gateway ตามข้อจำกัดของระบบเดิม
4. ทดสอบก่อนขึ้น Production ควรมี Test Environment หรืออย่างน้อยต้องมี Backup และ Rollback Plan ที่ชัดเจน
5. บังคับใช้และติดตามผล ตรวจสอบ Log เหตุการณ์ผิดปกติ และติดตามว่ามีบัญชีใดที่ยังไม่ได้เปิด MFA

การเพิ่ม MFA จึงไม่ได้หมายความว่าองค์กรต้องรื้อเว็บไซต์เดิมและสร้างใหม่ทั้งหมด ในหลายกรณีสามารถเพิ่ม TOTP เข้าไปใน Authentication Flow ของระบบที่มีอยู่ หรือใช้ Authentication Gateway เข้ามาสร้างชั้นป้องกันเพิ่มเติมได้