MFA แบบไหนกันฟิชชิงได้จริง ทำไม passkey ปลอดภัยกว่ารหัส OTP

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

CISA เขียนไว้ตรง ๆ ใน fact sheet เรื่อง implementing phishing-resistant MFA (ตุลาคม พ.ศ. 2565) ว่า MFA แต่ละรูปแบบปลอดภัยไม่เท่ากัน แต่ MFA แบบไหนก็ยังดีกว่าไม่มีเลย บทความนี้ไล่ตอบคำถามที่ผมอยากรู้คำตอบ ถ้าต้องเลือก second factor วันนี้ ไม่ว่าจะเลือกให้ตัวเองหรือให้ทีม ทุกคำตอบมีลิงก์ไปยังมาตรฐานหรือแนวปฏิบัติที่เป็นต้นทางครับ

Q: อะไรนับเป็น "factor"

factor คือ ประเภท ของหลักฐาน fact sheet ของ CISA นิยาม MFA ว่าเป็นการแสดง authenticator ตั้งแต่สองชิ้นขึ้นไปที่ ต่างประเภทกัน ได้แก่ สิ่งที่รู้ สิ่งที่มี หรือสิ่งที่เป็น (CISA)

password สองตัวก็ยังนับเป็น factor เดียว และแนวปฏิบัติด้าน authentication ฉบับปัจจุบันของ NIST คือ SP 800-63B-4 (ฉบับ final กรกฎาคม พ.ศ. 2568) ยังเพิ่มประเด็นที่คนมักมองข้ามว่า biometric ไม่นับเป็น authenticator ด้วยตัวเอง ต้องใช้คู่กับ authenticator ที่จับต้องได้ เช่น มือถือหรือ key ที่ทำหน้าที่จับคู่ลายนิ้วมือหรือใบหน้า

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

Q: ผู้โจมตีผ่าน SMS code และ push prompt ไปได้อย่างไร

มีอยู่ไม่กี่เส้นทางที่มีการบันทึกไว้ชัดเจน CISA ระบุภัยคุกคามต่อ MFA ไว้สี่อย่าง คือ phishing, push bombing, การใช้จุดอ่อนของ SS7 ในเครือข่ายโทรศัพท์ และ SIM swap (CISA)

เส้นทางที่ 1: ขอรหัสไปตรง ๆ

การโจมตีที่ง่ายที่สุดคือหน้าล็อกอินปลอม ตัวอย่างของ CISA เองคือ ผู้ใช้ได้รับอีเมล เข้าไปที่เว็บที่ทำหน้าตาเลียนแบบ portal ล็อกอินของบริษัท แล้วพิมพ์ username, password และ รหัสหกหลักจาก authenticator app ลงไป ใครก็ตามที่ได้ทั้งสามอย่างไปก็ลองใช้กับเว็บจริงได้ก่อนที่รหัสจะหมดอายุ

แบบที่ขัดเกลามากกว่าคือวาง proxy ไว้ตรงกลาง Microsoft อธิบายแคมเปญขนาดใหญ่ลักษณะนี้ไว้เมื่อ พ.ศ. 2565 ว่าเว็บฟิชชิงนั่งอยู่ระหว่างผู้ใช้กับหน้า sign-in จริง หน้าตาจึงเหมือนกันทุกอย่าง และมันเก็บได้ทั้ง password และ session cookie ที่ออกให้หลัง MFA ผ่านแล้ว เมื่อมี cookie นั้น ผู้โจมตีก็ข้ามขั้นตอน sign-in ไปได้เลย Microsoft ระบุว่านี่ไม่ใช่ช่องโหว่ของ MFA เอง ผู้โจมตีแค่ขโมย session ที่ MFA สร้างขึ้นมา (Microsoft Security blog) MITRE ATT&CK จัดตำแหน่งการโจมตีแบบนี้ไว้ใต้ Adversary-in-the-Middle (T1557) และระบุว่าใช้ดักเก็บ credential ได้ รวมถึง access token และ session cookie

เส้นทางที่ 2: ทำให้ผู้ใช้เหนื่อยจนยอม

ถ้าผู้โจมตีมี password อยู่แล้ว และบัญชีใช้ push notification แบบ "แตะเพื่ออนุมัติ" เขาก็แค่ล็อกอินซ้ำไปเรื่อย ๆ ทุกครั้งจะมี prompt เด้งขึ้นบนมือถือของเหยื่อ MITRE เรียกเทคนิคนี้ว่า Multi-Factor Authentication Request Generation (T1621) คือผู้โจมตีถล่มผู้ใช้ด้วย push notification, SMS หรือสายโทรเข้า จนในที่สุดผู้ใช้กดยอมรับสักอัน ซึ่ง ATT&CK เรียกว่า "MFA fatigue" และระบุกลุ่มอย่าง APT29, LAPSUS$ และ Scattered Spider ว่าเคยใช้เทคนิคนี้

fact sheet เรื่อง number matching ของ CISA อธิบายว่าผู้โจมตีสร้าง prompt ได้เป็นร้อย ๆ ครั้งในเวลาสั้น ๆ คนที่เหนื่อยอยู่อาจกด "Approve" เพื่อให้มันหยุดเสียที หรือคิดเอาเองว่าต้องมีสักอันที่เป็นของจริง

                                  ┌───────────────────────────┐ 
  ATTACKER'S BROWSER              │ PLAIN PUSH            ▮▮▯ │ 
┌────────────────────────────┐    │───────────────────────────│ 
│ login.example.com          │    │                           │ 
│────────────────────────────│    │                           │ 
│ user  ✓  password ✓        │    │                           │ 
│                            │    │                           │ 
│ waiting for approval       │    │                           │ 
│                            │    │                           │ 
│                            │    │                           │ 
└────────────────────────────┘    │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  │                           │ 
                                  └───────────────────────────┘ 

วิธีแก้ในครึ่งหลังของแอนิเมชันคือ number matching หน้าจอ sign-in จะแสดงตัวเลข แล้วเราต้องพิมพ์ตัวเลขนั้นลงในแอปเพื่ออนุมัติ CISA อธิบายว่าที่ช่วยได้ก็เพราะเราอนุมัติคำขอไม่ได้ถ้าไม่ได้เห็นหน้าจอล็อกอิน (CISA) ใน Microsoft Authenticator นั้น number matching เปิดใช้กับ push notification ทุกรายการ และผู้ใช้เลือกปิดเองไม่ได้

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

เส้นทางที่ 3: ยึดเบอร์โทรศัพท์

รหัสที่ส่งทาง SMS หรือสายโทรเข้ามีความเสี่ยงเพิ่มอีกสองข้อ CISA อธิบายการใช้จุดอ่อนของ SS7 ซึ่งเป็นเครือข่าย signalling ของระบบโทรคมนาคม เพื่อดักเอารหัสที่ส่งทาง SMS หรือเสียง และ SIM swap ที่ผู้โจมตีหลอกให้ผู้ให้บริการมือถือย้ายเบอร์ของเราไปอยู่บน SIM ของเขา (CISA) CISA ถือว่า SMS และ voice เป็นทางเลือกสุดท้าย ใช้ได้แค่ชั่วคราวระหว่างเปลี่ยนไปใช้วิธีที่แข็งแรงกว่า ส่วน NIST SP 800-63B-4 จัดการส่งรหัสผ่านเครือข่ายโทรศัพท์ให้เป็นวิธีแบบ "restricted" และระบุว่าผู้ตรวจสอบ (verifier) ควรพิจารณาสัญญาณเสี่ยง เช่น การเปลี่ยน SIM หรือการย้ายค่ายเบอร์ ก่อนจะส่งรหัสผ่านช่องทางนี้ (SP 800-63B-4)

Q: แล้ว MFA แบบ "phishing-resistant" คืออะไร

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

CISA จัดอันดับวิธี MFA จากแข็งแรงที่สุดไปอ่อนที่สุดไว้ดังนี้ (CISA)

CISA ยังระบุว่า FIDO/WebAuthn เป็นทางเลือก phishing-resistant เพียงแบบเดียวที่ ใช้ได้แพร่หลาย วิธีที่อิง PKI อย่าง smart card ที่เจ้าหน้าที่รัฐบาลสหรัฐฯ ใช้ก็แข็งแรง แต่ต้องการการจัดการ identity ที่ผ่านการพัฒนามาจนเป็นระบบแล้ว และยังไม่ได้รับการรองรับในบริการทั่วไปอย่างกว้างขวาง ส่วน passkey ก็คือ FIDO แบบหนึ่ง ลองมาดูกันครับว่ามันทำงานอย่างไร

Q: passkey คืออะไร และรู้ได้อย่างไรว่าเว็บไหนเป็นของจริง

FIDO Alliance อธิบายว่า passkey คือสิ่งที่มาแทน password สร้างบนมาตรฐาน FIDO2 คือ WebAuthn และ CTAP เราปลดล็อก passkey แบบเดียวกับที่ปลดล็อกอุปกรณ์ เช่น ลายนิ้วมือ สแกนใบหน้า PIN หรือ pattern เบื้องหลังมันคือ key pair private key อยู่กับเรา เว็บไซต์เก็บไว้แค่ public key การ sign-in เป็นแบบ challenge-response เว็บส่ง challenge แบบสุ่มใหม่มาให้ อุปกรณ์ของเราเซ็นมัน แล้วเว็บตรวจลายเซ็นด้วย public key ที่ตัวเองเก็บไว้ ข้อมูล biometric ไม่เคยออกจากอุปกรณ์ (FIDO Alliance; Microsoft Learn)

ส่วนที่หยุดฟิชชิงได้คือวิธีที่ WebAuthn กำหนดขอบเขต (scope) ของแต่ละ credential ข้อกำหนด WebAuthn Level 3 (เป็น W3C Recommendation ตั้งแต่ 25 สิงหาคม พ.ศ. 2569) กำหนดให้ทุก credential มี Relying Party ID ซึ่งเป็นชื่อโดเมน browser จะยอมให้หน้าเว็บใช้ credential ได้ก็ต่อเมื่อ ID นั้นตรงกับโดเมนของหน้าเว็บเอง หรือเป็น registrable suffix ของโดเมนนั้น ตัวอย่างในข้อกำหนดคือ เว็บที่อยู่ที่ login.example.com ใช้ RP ID เป็น login.example.com หรือ example.com ได้ แต่ใช้ com ไม่ได้

ลองนึกถึง passkey ที่มี RP ID เป็น example.com ซึ่งสร้างไว้ที่ login.example.com กับหน้าฟิชชิงที่ login.examp1e.co ครับ

                                                                
                                      ┌───────────────────────┐ 
 ┌───────────┐                        │  login.examp1e.co     │ 
 │ PASSKEY   │                        o                       │ 
 │───────────│                        │  look-alike           │ 
 │         · │                        └───────────────────────┘ 
 │ for:      │                                                  
 │ example   │                                                  
 │    .com   │ o━┑                                              
 │ ·  ·      │                        ┌───────────────────────┐ 
 │    ·  ·   │                        │  login.example.com    │ 
 │ face/PIN  │                        o                       │ 
 │   [ ]     │                        │  [ lock ]             │ 
 └───────────┘                        └───────────────────────┘ 
                                                                
                                                                

ที่เว็บปลอม browser ไม่มี passkey สำหรับชื่อนั้นเลย จึงไม่มีอะไรให้พิมพ์ ให้กดอนุมัติ หรือให้รั่วออกไป เราไม่จำเป็นต้องสังเกตเห็นเลข 1 ที่แอบอยู่แทนตัว l เพราะ protocol สังเกตแทนเราแล้วครับ

ยังมีการตรวจชั้นที่สองฝั่ง server ด้วย browser ใส่ origin ของหน้าเว็บลงใน client data ที่ถูกเซ็น และข้อกำหนดระบุว่าเว็บต้องตรวจค่านี้และต้องไม่ยอมรับค่าที่ไม่คาดไว้ (WebAuthn หัวข้อ 13.4.9) authenticator data ยังมี hash ของ RP ID ที่เว็บตรวจเทียบกับของตัวเองอีกชั้น (WebAuthn หัวข้อ 7) proxy ส่งข้อมูลไปมาได้ก็จริง แต่สร้างลายเซ็นที่บอกว่า "ฉันถูกสร้างให้ origin ของจริง" ไม่ได้ ในเมื่อ browser เห็น origin อื่นอยู่ NIST เรียกคุณสมบัตินี้ว่า verifier name binding และยก WebAuthn เป็นตัวอย่าง (SP 800-63B-4) ส่วนเอกสารของ Microsoft เรียกว่า verifier impersonation resistance คือ authenticator จะตอบกลับให้เฉพาะเว็บที่ passkey ลงทะเบียนไว้เท่านั้น

Q: synced หรือ device-bound ควรใช้แบบไหน

passkey มีสองแบบ (FIDO Alliance; Microsoft Learn)

• Synced passkey ถูกคัดลอกไปมาระหว่างอุปกรณ์ของเราโดย passkey provider เช่น Apple iCloud Keychain หรือ Google Password Manager FIDO ระบุว่าการ sync นี้เข้ารหัสแบบ end-to-end ใน WebAuthn เรียก credential แบบนี้ว่า multi-device credential และมี flag "backup eligible" กับ "backup state" ที่เว็บอ่านได้ (WebAuthn หัวข้อ 6.1)
• Device-bound passkey ไม่เคยออกจากอุปกรณ์เครื่องเดียว ตัวอย่างที่เห็นบ่อยคือ hardware security key ซึ่ง FIDO อธิบายว่าให้ระดับความมั่นใจสูงที่สุด และยังใช้เป็น credential สำรองไว้กู้บัญชีได้ด้วย ถ้าเราเข้าอุปกรณ์ที่ sync ไว้ไม่ได้

ทั้งสองแบบเป็น phishing-resistant เพราะการตรวจ origin เหมือนกัน ความต่างอยู่ที่ว่าใครอื่นเข้าถึง key ได้บ้างครับ

แถวของ NIST มาจาก SP 800-63B-4 ซึ่งอนุญาตให้ใช้ syncable authenticator ที่ AAL2 แต่ห้ามใช้ที่ AAL3 ซึ่ง private key ต้อง export ออกไปไม่ได้ (SP 800-63B-4) แนวทางของ Microsoft ก็ไปทางเดียวกัน คือใช้ hardware security key (หรือ passkey ใน Microsoft Authenticator) กับอุตสาหกรรมที่มีการกำกับดูแลเข้มงวดและผู้ใช้ที่มีสิทธิ์สูง และใช้ synced passkey กับผู้ใช้ส่วนใหญ่ (Microsoft Learn)

ความเห็นของผม: สำหรับบัญชีส่วนตัว synced passkey ดีกว่า password คู่กับ SMS อยู่มาก ส่วนบัญชี admin ให้ใช้ key แบบ device-bound ครับ

Q: จะเริ่มอย่างไรดี

สำหรับบัญชีของตัวเอง

1. เริ่มที่บัญชีอีเมล เพราะเป็นบัญชีที่ใช้รีเซ็ตทุกอย่างที่เหลือ หน้า MFA ของ CISA ยังระบุบริการทางการเงิน โซเชียลมีเดีย ร้านค้าออนไลน์ รวมถึงบริการเกมและสตรีมมิง ว่าเป็นที่ที่ควรเปิด MFA
2. บริการไหนมี passkey ให้สร้างไว้เลย บริการไหนยังไม่มี ให้ใช้ authenticator app แทน SMS
3. ลงทะเบียนช่องทางเข้าบัญชีช่องทางที่สองไว้ก่อนที่จะต้องใช้ เช่น passkey บนอุปกรณ์อีกเครื่อง หรือ security key
4. prompt อนุมัติใดที่เราไม่ได้เป็นคนเริ่ม ให้ถือเป็นสัญญาณเตือน ไม่ใช่เรื่องน่ารำคาญ กดปฏิเสธแล้วเปลี่ยน password ครับ

สำหรับองค์กร

1. ทำบัญชีรายการก่อน ระบบไหนเก็บข้อมูลมีค่าที่สุด และผู้ใช้คนไหนมีสิทธิ์มากที่สุด CISA ยกตัวอย่างระบบอีเมล file server ระบบ remote access และ identity server ว่าเป็นระบบที่มักถูกโจมตี และยกผู้ดูแลระบบ (system administrator) ทนายความ และเจ้าหน้าที่ HR ว่าเป็นผู้ใช้ที่เป็นเป้าหมายมูลค่าสูง (CISA)
2. เริ่มจากจุดที่รองรับง่าย CISA ระบุว่าระบบอีเมลแบบ hosted และระบบ SSO ส่วนใหญ่รองรับ FIDO และแนะนำให้เจ้าหน้าที่ IT กับ help desk เป็นกลุ่มแรก
3. เปิด number matching ให้ MFA แบบ push ที่ยังเปลี่ยนไม่ได้ และจำกัดจำนวน prompt ที่ส่งได้ในช่วงเวลาหนึ่ง (MITRE T1621)
4. ใช้คู่กับ conditional access policy ที่พิจารณาสัญญาณอื่นด้วย เช่น สถานะของอุปกรณ์และตำแหน่ง IP เพื่อให้ session cookie ที่ถูกขโมยไปนำไปใช้จากที่อื่นได้ยากขึ้น (Microsoft Security blog)
5. เลิกใช้ SMS เป็นทางสำรองเมื่อทำได้ ประตูหน้าที่แข็งแรงช่วยได้ไม่มาก ถ้าประตูกู้บัญชีข้าง ๆ ยังอ่อนอยู่ครับ

สรุปสั้น ๆ

รหัส OTP และ push prompt ทำให้งานของผู้โจมตียากขึ้น และดีกว่าใช้ password อย่างเดียวมาก แต่ทั้งคู่ยังพึ่งให้คนต้องดูออกว่าหน้าเว็บปลอม หรือต้องปฏิเสธ prompt ครั้งที่ยี่สิบตอนเที่ยงคืนให้ได้ passkey และ authenticator แบบ FIDO/WebAuthn อื่น ๆ ย้ายการตัดสินใจนั้นออกจากมือคนไปไว้ที่ browser ซึ่งตรวจชื่อเว็บทุกครั้ง ใช้สิ่งที่มีอยู่วันนี้ไปก่อน แล้วค่อย ๆ ขยับไปใช้ passkey เมื่อบริการที่ใช้รองรับครับ

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

• CISA: Implementing Phishing-Resistant MFA (fact sheet, ตุลาคม พ.ศ. 2565)
• CISA: Implementing Number Matching in MFA Applications (fact sheet, ตุลาคม พ.ศ. 2565)
• CISA: More than a Password (MFA)
• MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
• MITRE ATT&CK: T1557 Adversary-in-the-Middle
• NIST SP 800-63B-4: Authentication and Authenticator Management (หน้าข้อมูลการเผยแพร่)
• W3C: Web Authentication Level 3
• FIDO Alliance: Passkeys
• Microsoft Learn: Passkeys (FIDO2) in Microsoft Entra ID
• Microsoft Learn: Number matching in Authenticator push notifications
• Microsoft Security blog: From cookie theft to BEC (AiTM phishing, กรกฎาคม พ.ศ. 2565)