2FA คืออะไร ยืนยันตัวตน 2 ขั้นตอนทำงานอย่างไร และวิธีเปิด 2FA ใน WordPress

2FA (Two-Factor Authentication) หรือการยืนยันตัวตน 2 ขั้นตอน คือวิธีพิสูจน์ว่าผู้ที่กำลังล็อกอินเป็นเจ้าของบัญชีจริง โดยต้องแสดงหลักฐาน 2 อย่างที่มาจากปัจจัยคนละประเภท เช่น รหัสผ่าน (สิ่งที่รู้) ร่วมกับรหัสจากแอปในโทรศัพท์ (สิ่งที่มี) ถ้ารหัสผ่านรั่วออกไปเพียงอย่างเดียว ผู้ไม่หวังดีก็ยังเข้าบัญชีไม่ได้ เพราะไม่มีปัจจัยที่สอง

สำหรับเว็บไซต์ WordPress หน้า wp-login.php เป็นประตูหลักที่ทุกคนบนอินเทอร์เน็ตเข้าถึงได้ การเปิด 2FA ให้บัญชีที่มีสิทธิ์สูงจึงเป็นมาตรการที่ลงทุนน้อยแต่ลดความเสี่ยงได้มาก

ปัจจัยการยืนยันตัวตน 3 ประเภท

มาตรฐาน NIST SP 800-63B ของสถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐฯ ซึ่งฉบับปัจจุบันคือ Revision 4 ที่เผยแพร่ในเดือนกรกฎาคม 2025 แบ่งปัจจัยการยืนยันตัวตน (authentication factor) ออกเป็น 3 ประเภท ดังนี้

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

2FA กับ MFA ต่างกันอย่างไร

MFA (Multi-Factor Authentication) คือการยืนยันตัวตนด้วยปัจจัยตั้งแต่ 2 ประเภทขึ้นไป หน่วยงานความมั่นคงไซเบอร์สหรัฐฯ (CISA) นิยามไว้ในเอกสาร Implementing Phishing-Resistant MFA (ตุลาคม 2022) ว่าผู้ใช้ต้องแสดงตัวยืนยันตัวตนสองอย่างขึ้นไปที่ต่างประเภทกัน ส่วน 2FA คือกรณีของ MFA ที่ใช้ 2 ประเภทพอดี 2FA ทุกแบบจึงเป็น MFA และหน้า More than a Password ของ CISA ระบุว่าผู้ใช้ที่เปิด MFA มีโอกาสถูกแฮกน้อยลงอย่างมีนัยสำคัญ

การถามรหัสผ่านแล้วตามด้วยคำถามลับไม่นับเป็น 2FA เพราะทั้งสองอย่างเป็น “สิ่งที่รู้” เหมือนกัน หลักสำคัญคือประเภทของปัจจัยต้องต่างกัน ไม่ใช่จำนวนขั้นตอน คู่มือ Two Step Authentication ของ WordPress ใช้คำว่า two-step authentication ในความหมายเดียวกัน

ทำไมรหัสผ่านอย่างเดียวจึงไม่พอ

คู่มือความปลอดภัยของ WordPress ยกคำของ WordPress Security Team ไว้ว่า จุดที่อ่อนที่สุดของความปลอดภัยในทุกสิ่งที่ทำออนไลน์คือรหัสผ่าน (WordPress Advanced Administration) การโจมตีที่อาศัยจุดอ่อนนี้มีรูปแบบหลักดังนี้

• Credential stuffing คือการนำคู่ชื่อผู้ใช้และรหัสผ่านที่หลุดจากเว็บไซต์อื่นมาลองล็อกอิน ตามนิยามใน OWASP Credential Stuffing Prevention Cheat Sheet ถ้าใช้รหัสผ่านซ้ำกับบริการที่เคยรั่ว ความยาวของรหัสผ่านก็ไม่ช่วย
• Brute force และ password spraying คือการเดารหัสผ่านจำนวนมากด้วยโปรแกรมอัตโนมัติ อ่านกลไกได้ที่ Brute Force Attack คืออะไร และป้องกันใน WordPress อย่างไร
• Phishing คือการหลอกให้กรอกรหัสผ่านในหน้าเว็บปลอมที่หน้าตาเหมือนหน้าล็อกอินจริง ผู้ใช้ที่ระวังตัวก็ยังพลาดได้ถ้าหน้าปลอมทำมาแนบเนียน

OWASP ระบุว่า MFA เป็นการป้องกันที่ดีที่สุดอย่างชัดเจนสำหรับการโจมตีเกี่ยวกับรหัสผ่านส่วนใหญ่ รวมถึง credential stuffing และ password spraying และอ้างงานวิจัยของ Microsoft ว่า MFA จะป้องกันการถูกยึดบัญชีได้ 99.9% (OWASP) ตัวเลขนี้มาจากบัญชีในระบบของ Microsoft จึงไม่ใช่การรับประกันสำหรับทุกเว็บไซต์ จากเคสที่เราแก้ บัญชีแอดมิน WordPress ที่รหัสผ่านรั่วเป็นทางเข้าที่พบได้เป็นประจำ

ปัจจัยที่สองแต่ละแบบ เปรียบเทียบความปลอดภัย

ปัจจัยที่สองไม่ได้ปลอดภัยเท่ากันทุกแบบ CISA เรียงรูปแบบ MFA จากแข็งแรงที่สุดไปอ่อนที่สุดตามความเสี่ยงต่อการโจมตี 4 แบบ คือ phishing, push bombing, การใช้ช่องโหว่โปรโตคอล SS7 ของเครือข่ายโทรศัพท์ และ SIM swap (CISA, 2022) ตารางต่อไปนี้สรุปเทียบกับข้อกำหนดของ NIST SP 800-63B Revision 4

จุดยืนของ NIST ต่อ SMS และโทรศัพท์

NIST SP 800-63B Revision 4 หัวข้อ 3.1.3.3 ระบุว่า “Use of the PSTN for out-of-band verification is restricted” หรือการใช้เครือข่ายโทรศัพท์สาธารณะ (PSTN) ซึ่งรวม SMS และการโทรด้วยเสียง เพื่อยืนยันตัวตนแบบ out-of-band มีสถานะถูกจำกัด (restricted) ผู้ให้บริการต้องมีตัวยืนยันตัวตนแบบอื่นให้ผู้ใช้ทุกคนเลือก และควรพิจารณาสัญญาณความเสี่ยง เช่น การเปลี่ยนซิมหรือย้ายค่ายเบอร์ ก่อนส่งรหัส (NIST SP 800-63B) restricted จึงไม่ได้แปลว่าห้ามใช้ แต่ไม่ควรเป็นทางเลือกเดียว

อีเมลและ Push notification

NIST หัวข้อ 3.1.3.1 ระบุว่าอีเมล “SHALL NOT be used for out-of-band authentication” เพราะกล่องอีเมลอาจเปิดได้ด้วยรหัสผ่านอย่างเดียว และอีเมลอาจถูกดักหรือเปลี่ยนเส้นทางได้ (NIST SP 800-63B) สำหรับเว็บ WordPress รหัสทางอีเมลยังดีกว่าไม่มีปัจจัยที่สองเลย แต่ไม่ควรเป็นวิธีหลักของบัญชีผู้ดูแลระบบ

ส่วน push notification นั้น CISA อธิบายว่าการโจมตีแบบ push bombing คือการส่งคำขออนุมัติซ้ำๆ จนผู้ใช้กด “Accept” และแนะนำให้ใช้ number matching คือให้ผู้ใช้พิมพ์ตัวเลขที่แสดงบนหน้าล็อกอินลงในแอปก่อนอนุมัติ (CISA, 2022)

Passkey และกุญแจความปลอดภัย: แบบเดียวที่ต้านทาน Phishing

NIST นิยาม phishing resistance ว่าเป็นความสามารถของโปรโตคอลในการป้องกันไม่ให้ความลับหรือผลลัพธ์ของตัวยืนยันตัวตนรั่วไปยังผู้ปลอมเป็นเว็บไซต์ปลายทาง โดยไม่ต้องพึ่งความระมัดระวังของผู้ใช้ และระบุว่า OTP และการยืนยันแบบ out-of-band ไม่ต้านทาน phishing ขณะที่ WebAuthn ต้านทานได้ด้วยการผูกกับชื่อโดเมนของผู้ตรวจสอบ (verifier name binding) (NIST SP 800-63B)

มาตรฐาน Web Authentication Level 3 ของ W3C (สถานะ W3C Recommendation ณ 25 สิงหาคม 2026) อธิบายว่าข้อมูลรับรองแต่ละชุดผูกอยู่กับเว็บไซต์ (Relying Party) ที่สร้างมัน เว็บปลอมที่โดเมนต่างออกไปจึงใช้ไม่ได้ FIDO Alliance นิยาม passkey ว่าเป็นข้อมูลรับรองตามมาตรฐาน FIDO ที่เก็บในโทรศัพท์ คอมพิวเตอร์ หรือกุญแจความปลอดภัย และใช้ด้วยวิธีเดียวกับการปลดล็อกอุปกรณ์

NIST กำหนดว่าที่ระดับ AAL2 ผู้ให้บริการต้องมีทางเลือกที่ต้านทาน phishing อย่างน้อยหนึ่งแบบ และที่ระดับ AAL3 ต้องต้านทาน phishing เสมอ (NIST SP 800-63B)

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

TOTP (Time-Based One-Time Password) เป็นอัลกอริทึมตามมาตรฐาน RFC 6238 ของ IETF (พฤษภาคม 2011) ซึ่งต่อยอดจาก HOTP ใน RFC 4226 หลักการทำงานมี 3 ส่วน

1. กุญแจลับร่วม (shared secret) ตอนตั้งค่า เว็บไซต์สร้างกุญแจลับขึ้นมาหนึ่งชุดและแสดงเป็น QR code แอปในโทรศัพท์สแกนแล้วเก็บกุญแจนี้ไว้ ทั้งเว็บและแอปจึงมีกุญแจชุดเดียวกัน หลังจากนั้นไม่ต้องส่งกุญแจผ่านเครือข่ายอีก
2. ตัวนับเวลา ทั้งสองฝั่งคำนวณค่า T = (เวลา Unix ปัจจุบัน − T0) / X ปัดเศษลง โดย T0 ค่าเริ่มต้นคือ 0 และ X คือช่วงเวลา (time step) ซึ่ง RFC แนะนำค่าเริ่มต้น 30 วินาที
3. คำนวณรหัส นำกุญแจลับและค่า T เข้าฟังก์ชัน HMAC (ค่าเริ่มต้นคือ HMAC-SHA-1 และเลือกใช้ SHA-256 หรือ SHA-512 ได้) แล้วตัดผลลัพธ์ให้เหลือตัวเลขสั้นๆ แอปส่วนใหญ่แสดงเป็นรหัส 6 หลัก

เว็บไซต์คำนวณด้วยสูตรเดียวกันแล้วเทียบผล ถ้าตรงกันแปลว่าผู้ใช้ถือกุญแจลับอยู่จริง ผลที่ตามมาคือนาฬิกาต้องตรงกัน ถ้าเวลาในโทรศัพท์หรือเซิร์ฟเวอร์คลาดมาก รหัสจะไม่ผ่าน และรหัสที่ถูกขโมยใช้ได้เพียงช่วงสั้นๆ แต่ก็ยังพอให้ phishing แบบเรียลไทม์ใช้ได้ นอกจากนี้ QR code ตอนตั้งค่ามีกุญแจลับอยู่ข้างใน ไม่ควรถ่ายภาพหน้าจอเก็บไว้

วิธีเปิด 2FA ใน WordPress ด้วยปลั๊กอิน Two-Factor

ณ ตุลาคม 2026 WordPress Core ยังไม่มี 2FA ในตัว คู่มือของ WordPress แนะนำให้เพิ่มผ่านปลั๊กอินจาก Plugin Directory ตัวเลือกที่เราแนะนำสำหรับเว็บทั่วไปคือ Two-Factor ซึ่งเผยแพร่ในชื่อผู้พัฒนา WordPress.org เป็นเวอร์ชัน 0.17.0 อัปเดตล่าสุด 28 กันยายน 2026 และต้องใช้ WordPress 7.0 ขึ้นไป

วิธีที่ปลั๊กอินรองรับ ณ เวอร์ชันนี้ ได้แก่

• Authenticator App (TOTP) ทำงานกับแอปอย่าง Google Authenticator, Authy หรือ 1Password ผู้พัฒนาระบุว่าแนะนำ
• Backup Codes รหัสสำรองใช้ครั้งเดียว สร้างครั้งละ 10 รหัส ผู้พัฒนาระบุว่าแนะนำ
• Email Codes ส่งรหัสใช้ครั้งเดียวไปยังอีเมลของบัญชี
• FIDO U2F Security Keys ถูกถอดออกแล้วเพราะเบราว์เซอร์เลิกรองรับ ถ้าต้องการ passkey หรือกุญแจความปลอดภัย ผู้พัฒนาแนะนำปลั๊กอินเสริม Two-Factor Provider: WebAuthn

ขั้นตอนตั้งค่า (ตามคำอธิบายในหน้าปลั๊กอิน ณ ตุลาคม 2026)

1. สำรองเว็บก่อน และเปิดหน้าต่างเบราว์เซอร์ที่ล็อกอินค้างไว้อีกหนึ่งหน้าต่างระหว่างตั้งค่า ถ้าตั้งผิดจะยังแก้กลับได้
2. ติดตั้งปลั๊กอิน ไปที่ Plugins → Add New Plugin ค้นหา “Two Factor” เลือกตัวที่ผู้พัฒนาคือ WordPress.org แล้วกด Install Now และ Activate
3. เปิดหน้าโปรไฟล์ ไปที่ Users → Profile (หน้าโปรไฟล์ของบัญชีตัวเอง) แล้วเลื่อนลงไปที่ส่วน Two-Factor Options
4. ตั้งค่าแอป Authenticator เปิดวิธี Authenticator App ระบบจะแสดง QR code ให้สแกนด้วยแอปในโทรศัพท์ แล้วพิมพ์รหัสที่แอปแสดงกลับลงในช่องเพื่อยืนยันว่าจับคู่สำเร็จ
5. สร้าง Backup Codes เปิดวิธี Backup Codes แล้วกดสร้างรหัส จะได้ 10 รหัส ดาวน์โหลดหรือพิมพ์เก็บไว้ทันที เพราะรหัสจะแสดงเพียงครั้งเดียว
6. เลือกวิธีหลัก กำหนดให้ Authenticator App เป็นวิธีหลัก (primary) ส่วน Backup Codes เป็นวิธีสำรอง
7. บันทึก กด Update Profile
8. ทดสอบ ล็อกอินในหน้าต่างไม่ระบุตัวตน (incognito) หลังใส่รหัสผ่าน ระบบต้องถามรหัส 6 หลักจากแอป ถ้าผ่านจึงค่อยปิดหน้าต่างที่ล็อกอินค้างไว้

ผู้ดูแลระบบมีหน้าตั้งค่าที่ Settings → Two-Factor สำหรับปิดวิธีที่ไม่ต้องการใช้ทั้งเว็บ เช่น Email Codes (Two-Factor) ผู้ใช้แต่ละคนต้องตั้งค่า 2FA ของตัวเอง และ ณ เวอร์ชัน 0.17.0 ปลั๊กอินยังไม่มีหน้าตั้งค่าบังคับใช้ 2FA ตามบทบาท ต้องเขียนเงื่อนไขเองผ่าน filter

สำหรับการล็อกอินผ่าน REST API และ XML-RPC ปลั๊กอินมี filter two_factor_user_api_login_enable ให้จำกัดเหลือเฉพาะ Application Passwords ถ้าเว็บไม่ได้ใช้ XML-RPC การปิดไปเลยง่ายกว่า อ่านที่ XML-RPC คืออะไร ควรปิดใน WordPress ไหม

ทางเลือก: 2FA ใน Wordfence

ถ้าเว็บใช้ Wordfence อยู่แล้ว ปลั๊กอินหลัก Wordfence Security (เวอร์ชัน 9.0.2 ณ ตุลาคม 2026) มีหมวด Login Security ที่รองรับ 2FA ด้วยแอป TOTP, passkey, CAPTCHA หน้าล็อกอิน และตัวเลือกเพิ่ม 2FA หรือปิด XML-RPC ควรใช้ 2FA จากปลั๊กอินเพียงตัวเดียว ส่วนปลั๊กอินแยก Wordfence Login Security ถูกปิดถาวรใน WordPress.org ตั้งแต่ 17 สิงหาคม 2026 ตามคำขอของผู้พัฒนา เว็บที่ยังใช้อยู่ควรย้ายไปตัวหลักหรือ Two-Factor ดูภาพรวมได้ที่ Wordfence คืออะไร เหมาะกับใคร

Backup Codes และสิ่งที่ต้องทำเมื่อโทรศัพท์หาย

คู่มือ WordPress เตือนว่าขั้นตอนเพิ่มเติมของ 2FA อาจทำให้ผู้ใช้ตัวจริงเข้าระบบไม่ได้ถ้าไม่มีอุปกรณ์ที่สองอยู่กับตัว (WordPress Advanced Administration) จึงควรวางแผนกู้บัญชีไว้ตั้งแต่ตอนเปิด 2FA ลำดับที่แนะนำมีดังนี้

1. ใช้ Backup Code ที่หน้าถามรหัส เลือกใช้วิธีสำรอง แล้วพิมพ์ Backup Code หนึ่งรหัส แต่ละรหัสใช้ได้ครั้งเดียว เมื่อเข้าได้แล้วให้ตั้งค่าแอป Authenticator ในโทรศัพท์เครื่องใหม่และสร้าง Backup Codes ชุดใหม่ทันที
2. ให้ผู้ดูแลระบบอีกคนรีเซ็ต ผู้ดูแลระบบไปที่ Users → All Users กด Edit ที่บัญชีที่เข้าไม่ได้ เลื่อนไปที่ Two-Factor Options เอาเครื่องหมายออกจากทุกวิธี แล้วกด Update User บัญชีนั้นจะล็อกอินด้วยรหัสผ่านได้อีกครั้ง ถ้ามีสิทธิ์เข้าเซิร์ฟเวอร์ ทำได้ด้วยคำสั่ง wp two-factor disable <user> --yes (Two-Factor FAQ)
3. ทางสุดท้าย: ปิดปลั๊กอินผ่าน FTP ถ้าเว็บมีผู้ดูแลระบบคนเดียวและไม่มี Backup Code เข้า FTP หรือ File Manager ของ Hosting ไปที่ wp-content/plugins/ แล้วเปลี่ยนชื่อโฟลเดอร์ two-factor เป็นชื่ออื่น เช่น two-factor.off WordPress จะหาปลั๊กอินไม่เจอและปิดการทำงานให้ เป็นหลักการเดียวกับที่ FAQ Troubleshooting ของ WordPress ใช้กับโฟลเดอร์ plugins ทั้งโฟลเดอร์ เมื่อล็อกอินได้แล้วให้เปลี่ยนชื่อกลับ เปิดใช้งานอีกครั้ง และตั้งค่า 2FA ใหม่ ระหว่างนั้น 2FA จะหายไปจากทุกบัญชี จึงควรทำให้เสร็จเร็วที่สุด

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

Backup Codes ควรเก็บแยกจากโทรศัพท์ เช่น ในโปรแกรมจัดการรหัสผ่านหรือพิมพ์บนกระดาษ ถ้าเก็บในเครื่องเดียวกับแอป Authenticator เครื่องหายครั้งเดียวจะเสียทั้งสองอย่าง

ควรบังคับใช้ 2FA กับบัญชีใดบ้าง

บัญชีที่ควรเปิด 2FA เป็นอันดับแรกคือบัญชีที่ถ้าถูกยึดแล้วเปลี่ยนแปลงเว็บได้มาก ตามบทบาทใน Roles and Capabilities ของ WordPress และ บทบาทที่ WooCommerce เพิ่มเข้ามา

ก่อนเริ่ม ควรตรวจรายชื่อผู้ดูแลระบบ บัญชีที่ไม่มีใครใช้แล้วควรลบหรือลดสิทธิ์ อ่านเหตุผลที่ User Admin หลายคนใน WordPress เสี่ยงอย่างไร

# รายชื่อบัญชีที่มีบทบาท Administrator ทั้งหมด
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# รายชื่อ Shop Manager ของ WooCommerce
wp user list --role=shop_manager --fields=ID,user_login,user_email

# ดูว่าบัญชีหนึ่งเปิด 2FA แล้วหรือยัง (ต้องติดตั้งปลั๊กอิน Two-Factor)
wp two-factor status admin_login

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

2FA ไม่ได้ป้องกันทุกอย่าง

2FA ปกป้องขั้นตอนการล็อกอิน แต่ไม่ได้ปิดช่องทางอื่น

• ช่องโหว่ในปลั๊กอินหรือ Theme บางช่องโหว่เข้าถึงเว็บได้โดยไม่ผ่านหน้าล็อกอิน การอัปเดตจึงยังจำเป็น
• Phishing แบบเรียลไทม์ เว็บปลอมที่ส่งต่อรหัสผ่านและ OTP ไปเว็บจริงทันทีผ่าน TOTP ได้
• Session ถูกขโมย ถ้าเครื่องผู้ดูแลติดมัลแวร์ ผู้โจมตีไม่ต้องล็อกอินใหม่
• บัญชี Hosting, FTP และฐานข้อมูล ควรเปิด 2FA ในระบบของผู้ให้บริการด้วยถ้ารองรับ

ดูมาตรการชั้นอื่นได้ที่ WordPress Security Checklist สำหรับเจ้าของเว็บไซต์ และ วิธีป้องกัน WordPress โดนแฮกเบื้องต้น ถ้าต้องการให้ผู้เชี่ยวชาญตั้งค่า 2FA ตรวจบัญชีผู้ใช้ และปิดช่องทางอื่นไปพร้อมกัน ดูรายละเอียดบริการ WordPress Security Hardening

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

แหล่งอ้างอิง

1. National Institute of Standards and Technology. (2025). NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://pages.nist.gov/800-63-4/sp800-63b.html
2. National Institute of Standards and Technology. (2025). SP 800-63B-4 (Final) — publication details. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://csrc.nist.gov/pubs/sp/800/63/b/4/final
3. Cybersecurity and Infrastructure Security Agency. (2022). Implementing Phishing-Resistant MFA. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
4. Cybersecurity and Infrastructure Security Agency. (ม.ป.ป.). More than a Password. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.cisa.gov/MFA
5. M’Raihi, D., Machani, S., Pei, M., & Rydell, J. (2011). RFC 6238: TOTP: Time-Based One-Time Password Algorithm. IETF. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://datatracker.ietf.org/doc/html/rfc6238
6. World Wide Web Consortium. (2026). Web Authentication: An API for accessing Public Key Credentials — Level 3. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.w3.org/TR/webauthn-3/
7. FIDO Alliance. (ม.ป.ป.). Passkeys. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://fidoalliance.org/passkeys/
8. OWASP Foundation. (ม.ป.ป.). Credential Stuffing Prevention Cheat Sheet. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html
9. WordPress.org. (ม.ป.ป.). Two Step Authentication — Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/mfa/
10. WordPress.org. (2026). Two Factor (plugin), version 0.17.0. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/plugins/two-factor/
11. Kolesnykov, V. (ม.ป.ป.). Two-Factor Provider: WebAuthn (plugin). สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/plugins/two-factor-provider-webauthn/
12. Wordfence. (2026). Wordfence Security – Firewall, Malware Scan, and Login Security (plugin), version 9.0.2. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/plugins/wordfence/
13. WordPress.org. (2026). Wordfence Login Security (plugin closed). สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/plugins/wordfence-login-security/
14. WordPress.org. (2026). FAQ Troubleshooting. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/faq-troubleshooting/
15. WordPress.org. (ม.ป.ป.). Roles and Capabilities. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/roles-and-capabilities/
16. WooCommerce. (ม.ป.ป.). Roles and Capabilities. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://woocommerce.com/document/roles-capabilities/
17. WordPress.org. (ม.ป.ป.). wp user list — WP-CLI Commands. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/user/list/