บทที่ 6 · Part 2 — Identity & Web Security
Strong Authentication & Account Recovery
MFA, passkeys, phishing resistance, step-up authentication, authenticator binding และ recovery ที่ไม่กลายเป็นทางลัดยึดบัญชี
ระบบอาจบังคับ MFA ทุกบัญชี แต่ attacker ยังยึดบัญชีได้ด้วยหน้า phishing ที่รับ password และ OTP แล้ว relay ไปยังระบบจริงทันที หรือโทรหา support เพื่อขอเปลี่ยนเบอร์โทรโดยอ้างว่า อุปกรณ์หาย Strong authentication จึงต้องพิจารณา resistance ของ authenticator และ recovery ทั้งเส้นทาง ไม่ใช่นับจำนวน factors เท่านั้น
Learning Outcomes
- แยก authentication factor, MFA, assurance และ phishing resistance ได้
- เลือก TOTP, push, SMS, passkey และ hardware authenticator ตาม threat model ได้
- อธิบาย WebAuthn/passkey และข้อแตกต่างของ syncable กับ device-bound credential ได้
- ออกแบบ step-up authentication ที่ผูกกับ sensitive action ได้
- สร้าง account recovery และ authenticator-change flow ที่มี notification/audit ครบ
MFA ไม่ได้แปลว่า Phishing-Resistant
authentication factors แบ่งกว้าง ๆ เป็น:
- Something known — password, PIN
- Something possessed — device, cryptographic key, OTP authenticator
- Something inherent — biometric characteristic
2 ขั้นตอนที่มาจาก factor เดียวไม่จำเป็นต้องเป็น MFA และ MFA หลายชนิดยังถูก phishing/relay ได้
| Authenticator | จุดแข็ง | ข้อจำกัดสำคัญ |
|---|---|---|
| Password | ใช้ได้กว้างและ recovery คุ้นเคย | phishable, reused, guessed ได้ |
| TOTP | ไม่พึ่ง mobile network | code ถูก relay/phish ได้ และ shared seed ต้องป้องกัน |
| SMS/PSTN OTP | เข้าถึงผู้ใช้ได้กว้าง | SIM swap, number recycle, signaling/relay risk; เป็น restricted authenticator |
| Push approval | user experience ดี | fatigue bombing และ blind approval |
| Passkey/WebAuthn | verifier-bound และ phishing-resistant | device/account recovery, ecosystem และ attestation policy |
| Hardware security key | phishing-resistant และแยกอุปกรณ์ได้ | distribution, loss และ recovery cost |
NIST SP 800-63B-4 กำหนดให้ AAL2 ต้องมี phishing-resistant option ให้เลือก และ AAL3 ต้องใช้ public-key authenticator ที่ phishing-resistant พร้อม non-exportable private key และ 2 factors การนำระดับเหล่านี้ไปใช้ต้องดูบริบทของมาตรฐาน ไม่ใช้ label แทน threat model
ทำความเข้าใจ Phishing Resistance
password และ OTP เป็นค่าที่ผู้ใช้พิมพ์ให้ verifier ใดก็ได้ หน้า phishing จึงรับค่าแล้วส่งต่อได้ WebAuthn ผูก cryptographic operation กับ relying-party identity ที่ authenticator ตรวจสอบ credential สำหรับ domain หนึ่งจึงไม่สร้าง proof ที่ valid ให้อีก domain
server ยังต้องตรวจ challenge เป็น random/single-use/short-lived, origin/RP ID, credential status, signature counter ตาม authenticator behavior และ bind ผลกับ authentication transaction
Passkey ไม่แทน Authorization
passkey พิสูจน์การควบคุม credential ของ subject แต่ไม่ได้อนุญาต resource/action และไม่ได้ยืนยันว่าธุรกรรมจำนวนหรือ beneficiary ที่แสดงในอีกหน้าหนึ่งไม่ถูกเปลี่ยน
Syncable และ Device-Bound Passkeys
passkey อาจ sync ผ่าน platform account หรือผูกกับ hardware/device เฉพาะ:
| Model | ประโยชน์ | Trade-off |
|---|---|---|
| Syncable | ใช้หลายอุปกรณ์และ recovery ง่าย | assurance พึ่ง cloud account/recovery และ key export/sync model |
| Device-bound | private key ไม่ย้ายง่าย เหมาะกับ assurance สูง | ต้อง enroll สำรองและจัดการอุปกรณ์หาย |
| Hardware key | แยกจาก endpoint และควบคุม inventory ได้ | logistics, compatibility และ replacement |
NIST AAL3 ต้องการ non-exportable private key ดังนั้น syncable/exportable passkey ทั่วไปอาจเหมาะกับ assurance ต่ำกว่า แต่ไม่ตรงเงื่อนไข AAL3 การเลือกควรผูกกับ asset, user population และ recovery
Biometrics เป็น Activation Factor
Face/fingerprint บนอุปกรณ์มักใช้ปลดล็อก private key ใน secure hardware ไม่ควรส่ง biometric template ไปยัง backend หรือเชื่อ boolean callback จาก application อย่างเดียว
สิ่งที่ backend ตรวจได้คือ cryptographic proof จาก key ที่ถูก activate ตาม platform policy ส่วน assurance ของ biometric, retry limit, fallback PIN และ secure hardware เป็นส่วนหนึ่งของ device/platform threat model
Biometric เปลี่ยนไม่ได้เหมือน Password
การรั่วของ biometric template มีผลระยะยาว จึงควรเก็บและ match ภายใน trusted platform boundary เมื่อเป็นไปได้ พร้อมมี fallback/recovery ที่ไม่ลด assurance ลงอย่างเงียบ ๆ
Push และ OTP ต้องออกแบบเพื่อต้าน Abuse
simple push ที่มีเพียง Allow/Deny ทำให้ attacker ส่ง prompt ซ้ำจนผู้ใช้กดยอมรับ แนวทางที่ดีกว่าอาจรวม:
- number matching หรือ context ที่ผู้ใช้ต้องเปรียบเทียบ
- แสดง device/location/action โดยไม่รั่วข้อมูลละเอียด
- จำกัดจำนวนและ rate ของ prompt
- หยุด flow และแจ้งเตือนเมื่อ deny/fraud report
- ห้าม fallback อัตโนมัติไปยัง factor ที่อ่อนกว่า
manual-entry OTP และ push ยังไม่ phishing-resistant เพราะ attacker relay ได้ จึงไม่ควรเขียน requirement เพียง “มี MFA” โดยไม่ระบุ authenticator และ attack resistance
SMS เป็น Restricted Authenticator
เมื่อจำเป็นต้องรองรับ SMS/PSTN:
- มี authenticator ทางเลือก
- ตรวจ recent SIM change/number porting และ abnormal behavior ตามข้อมูลที่ได้รับอนุญาต
- จำกัด code lifetime/attempt และผูกกับ transaction
- ไม่แสดง code ใน notification/log/analytics
- วางแผนเมื่อเบอร์ถูก recycle หรือเปลี่ยนเจ้าของ
Email ใช้แจ้งเตือนหรือส่ง recovery information บางรูปแบบได้ แต่ NIST ไม่ยอมรับ email เป็น out-of-band authentication channel สำหรับ authenticator proof
Step-Up ต้องผูกกับ Action
step-up เพิ่ม assurance เมื่อ context หรือ action มีความเสี่ยงสูง เช่นเพิ่ม beneficiary, เปลี่ยน authenticator, export ข้อมูล หรืออนุมัติ payout
proof ต้องมี expiry, single-use state และผูกกับรายละเอียดที่สำคัญ เช่น amount, currency, source, beneficiary และ operation ID การ login ใหม่อย่างเดียวไม่ช่วยถ้า attacker เปลี่ยน transaction หลัง proof สำเร็จ
Recovery คือ Authentication Path เต็มรูปแบบ
account recovery มักเป็นจุดอ่อนที่สุด เพราะถูกออกแบบหลัง login flow และมีแรงกดดันจาก support
ช่องทางที่อาจใช้ร่วมกันตาม assurance:
- saved recovery codes ที่สร้างด้วย entropy สูงและเก็บ hash ฝั่ง server
- recovery contact ที่ลงทะเบียนและยืนยันล่วงหน้า
- authenticator สำรอง/device-bound credential อีกชุด
- repeated identity proofing ตาม policy
- supervised/manual process ที่มี separation of duties
security question หรือ Knowledge-Based Authentication เช่นวันเกิด/ชื่อมารดาไม่เหมาะเป็น secret เพราะข้อมูลหา, เดา, ซื้อ หรือหลอกถามได้
Recovery Flow ที่มี Guardrails
- รับ request โดยไม่เปิดเผยว่า account มีอยู่หรือไม่
- rate-limit และสร้าง recovery transaction ที่หมดอายุ
- ใช้ recovery methods ตาม assurance policy มากกว่า 1 สัญญาณเมื่อ risk สูง
- ป้องกัน operator คนเดียว override control สำคัญ
- bind authenticator ใหม่และ revoke/จำกัดของเก่าตาม policy
- ส่ง independent notification ไปยังช่องทางเดิม
- จำกัด sensitive action ชั่วคราวหรือส่ง review เมื่อ threat model กำหนด
- บันทึก evidence โดยไม่เก็บ proof/secret
Cooling Period เป็น Business/Risk Decision
การหน่วงถอนเงินหลัง recovery อาจลด account takeover loss แต่กระทบผู้ใช้จริงที่ต้องเข้าถึงเงิน ระยะเวลา, exception, manual review และ customer communication ต้องถูกกำหนดโดยผู้มีอำนาจ จาก Product, Operations, Security, Risk และ Compliance ไม่ควร hardcode จากตัวอย่าง
Authenticator Binding และ Removal
การเพิ่ม/ลบ passkey, TOTP seed หรือเบอร์โทรควรถือเป็น privileged action:
- reauthenticate ด้วย factor ที่เหมาะสม ไม่เชื่อ session เก่าอย่างเดียว
- แสดงรายการ authenticator พร้อมเวลา/อุปกรณ์โดยไม่รั่ว detail
- ป้องกัน attacker เพิ่ม factor ของตนแล้วลบ factor เดิมทั้งหมดทันที
- แจ้งช่องทางเดิมและให้ report/revoke ได้
- revoke session/token ที่ assurance ไม่ตรง policy ใหม่
- audit actor, approver, old/new state และ outcome
support override ต้องใช้ short-lived privileged access, maker-checker ตาม risk และห้าม operator อนุมัติ request ที่ตนสร้าง
Recovery และ Authentication Telemetry
สัญญาณที่ควรเชื่อมกัน:
- push/OTP request จำนวนมากตามด้วย success
- recovery หลังเปลี่ยน SIM/device/location
- เพิ่ม authenticator แล้วลบ factor เดิม
- recovery ตามด้วย beneficiary/payout change
- support override นอกเวลา/volume ปกติ
- authenticator เดียวผูกหลาย account ผิด pattern
alert ต้องมี runbook, evidence และ authority สำหรับ freeze/revoke/review พร้อมระวัง privacy และ false positive
Testing Checklist
- requirement ระบุ authenticator type และ phishing resistance ไม่ใช้คำว่า MFA อย่างเดียว
- WebAuthn ตรวจ challenge, origin, RP ID, signature, expiry และ transaction state
- syncable/device-bound credential ถูกเลือกตาม assurance และ recovery model
- biometric ใช้ activate cryptographic key ไม่ส่ง template ไป backend โดยไม่จำเป็น
- push/OTP มี rate limit, transaction binding และไม่มี automatic weak fallback
- SMS มีทางเลือกและ signal สำหรับ SIM/number change ตาม policy
- step-up proof ผูกกับ sensitive action/version และใช้ซ้ำไม่ได้
- recovery ไม่ใช้ security question/KBA เป็นหลัก
- authenticator binding/removal มี reauth, notification, revocation และ audit
- human override มี least privilege และ separation of duties
สรุป
Strong authentication ไม่ได้วัดจากจำนวนหน้าที่ต้องผ่าน แต่จากความสามารถของ authenticator ในการต้าน phishing/replay, การผูก proof กับ verifier/action และ recovery ที่รักษา assurance เส้นทางสำรองทุกเส้นต้องถูก threat model เท่ากับเส้นทางหลัก