2FA và FIDO2/Passkeys trong Mobile Banking: Từ SMS OTP đến sinh trắc học
Hướng dẫn kiến trúc 2FA cho Mobile Banking: SMS OTP, TOTP/Smart OTP, FIDO2, WebAuthn, passkeys, sinh trắc học cục bộ, đăng ký thiết bị, step-up và khôi phục tài khoản.
ShanverseUpdated 11 min read— viewsLoading views
Passkeys & 2FA
Authentication
Payment Systems
Vì sao ngân hàng cần vượt qua SMS OTP?
SMS OTP đã giúp tách mật khẩu và mã dùng một lần sang hai kênh, nhưng không được thiết kế để chống phishing hiện đại. Kẻ tấn công có thể:
Dựng trang đăng nhập giả và relay OTP theo thời gian thực.
Thực hiện SIM swap/social engineering với nhà mạng.
Lợi dụng malware đọc notification/SMS hoặc accessibility.
Chiếm email/tài khoản cloud dùng cho recovery.
Thuyết phục khách đọc mã cho “nhân viên hỗ trợ”.
Soft OTP và Smart OTP giảm phụ thuộc vào mạng viễn thông, nhưng mã người dùng có thể đọc và nhập vẫn có thể bị phishing. FIDO2/passkeys thay đổi mô hình: challenge chỉ có thể được ký bởi private key đúng, cho đúng Relying Party.
So sánh ba thế hệ
Không nên hiểu mũi tên nâng cấp là “bật passkey rồi xóa OTP ngay”. Đây là chương trình migration theo rủi ro, thiết bị và khả năng recovery.
Comments
Authentication factor là gì?
Something you know: password, PIN.
Something you have: SIM, OTP app, điện thoại, security key, private key.
Something you are: biometric characteristic.
Một passkey có private key trong authenticator là possession factor. Nếu Relying Party yêu cầu User Verification, authenticator chỉ ký sau khi người dùng xác minh bằng biometric hoặc PIN thiết bị. Tuy nhiên, server không biết và không nhận mẫu sinh trắc học; nó nhận cờ user-verification cùng assertion đã ký.
Vì vậy câu “đăng nhập bằng Face ID” ở tầng UX thường có nghĩa: Face ID mở khóa credential mật mã trên thiết bị, không phải server face-matching người dùng mỗi lần.
FIDO2, WebAuthn, CTAP và Passkeys
WebAuthn: API để website/app tạo và sử dụng public-key credentials với Relying Party.
CTAP: giao thức giữa client/platform và authenticator ngoài hoặc roaming authenticator.
FIDO2: kết hợp WebAuthn và CTAP.
Passkey: FIDO credential được tối ưu cho đăng nhập không mật khẩu; có thể sync qua hệ sinh thái hoặc device-bound tùy loại.
Mỗi credential gắn với RP ID. Authenticator ký challenge cùng dữ liệu liên quan origin/RP, nên credential của domain ngân hàng thật không hoạt động trên domain phishing khác.
Kiến trúc tham khảo cho Mobile Banking
Mermaid
Loading diagram…
Private key không rời authenticator. Backend lưu credential ID, public key, sign counter/metadata phù hợp, user handle, trạng thái và timestamps.
Luồng đăng ký Passkey
Mermaid
Loading diagram…
Registration chỉ được phép sau một phiên đủ tin cậy. Với ngân hàng, thêm credential mới là hành động rủi ro cao: cần reauthentication, risk checks, notification ngoài băng và cooling-off/limit phù hợp policy.
Những gì server phải kiểm tra
Challenge do server phát, random, dùng một lần và chưa hết hạn.
RP ID/origin hoặc native-app association đúng cấu hình.
Không tin deviceName, biometricPassed hoặc isSecureDevice do client tự gửi.
Luồng đăng nhập bằng Passkey
Mermaid
Loading diagram…
Authentication assertion phải ràng buộc với challenge hiện tại. Không cache một assertion để dùng lại. Sau xác thực, session vẫn cần chống token theft, replay và device compromise.
SMS OTP: dùng đúng khi chưa thể bỏ
Nếu còn SMS OTP:
Mã random đủ mạnh, thời hạn ngắn và dùng một lần.
Hash hoặc bảo vệ OTP ở server; không log plaintext.
Rate limit theo account, session, IP và device.
Giới hạn resend; mã mới phải có policy vô hiệu mã cũ rõ ràng.
Generic error để tránh account enumeration.
Phát hiện SIM change, number porting và velocity khi có nguồn tín hiệu hợp pháp.
Không dùng SMS làm recovery duy nhất cho tài khoản giá trị cao.
Nội dung không chứa link và cảnh báo không chia sẻ OTP.
OTP phải gắn với một authentication/transaction session, không phải mã toàn cục có thể dùng ở endpoint khác.
Soft OTP/TOTP
TOTP thường sinh mã từ shared secret và time step:
Các kiểm soát cần có:
Secret sinh bằng CSPRNG và mã hóa bằng KMS/HSM.
QR enrollment chỉ hiển thị trong phiên an toàn, dùng một lần.
Xác minh một mã trước khi activate.
Chấp nhận clock window nhỏ và ngăn replay cùng time step.
Rate limit, lock/risk escalation và audit.
Rotate/revoke seed khi nghi compromise.
Không đưa seed vào analytics, screenshot hoặc backup không kiểm soát.
TOTP tốt hơn SMS về kênh truyền nhưng vẫn không phishing-resistant vì người dùng có thể nhập mã vào website giả.
Smart OTP và Transaction Signing
“Smart OTP” không phải một chuẩn duy nhất. Trong banking, nó thường là OTP tích hợp trong app, device-bound, có thể mở khóa bằng PIN/biometric. Phiên bản mạnh hơn ký challenge chứa chi tiết giao dịch:
Khách phải thấy chính xác amount và beneficiary trên trusted UI trước khi xác nhận. Nếu backend chỉ yêu cầu “Approve transaction” chung chung, malware có thể thay giao dịch sau khi người dùng xác thực.
Dynamic linking cần bảo đảm dữ liệu hiển thị và dữ liệu được ký là cùng một payload canonical. Bất kỳ thay đổi amount/beneficiary nào cũng làm chữ ký không còn hợp lệ.
Passkey cho login khác transaction authorization
Passkey giải quyết xác thực với RP và có thể dùng cho step-up, nhưng “đã đăng nhập” không mặc nhiên có nghĩa “đã phê duyệt giao dịch 100 triệu”. Banking nên phân tách:
Sign-in authentication.
Session continuation.
Sensitive profile changes.
New beneficiary enrollment.
Payment authorization.
Credential/recovery changes.
Mỗi hành động có risk tier, freshness requirement và signed context. Với giao dịch, cần protocol/profile cho phép ràng buộc ý định khách hàng với nội dung giao dịch; không giả định một WebAuthn login assertion tự động dynamic-link mọi payment.
Sinh trắc học trong ứng dụng ngân hàng
Ứng dụng nên sử dụng API biometric của hệ điều hành để bảo vệ key trong Secure Enclave/TEE/Keystore khi thiết bị hỗ trợ. Không tự chụp ảnh khuôn mặt cho mỗi lần login để thay thế platform authentication.
Yêu cầu biometric/PIN cho mỗi thao tác nhạy cảm hoặc theo policy ngắn.
Gắn key use với user presence/user verification.
Chọn policy khi biometric enrollment trên thiết bị thay đổi.
Không lưu raw fingerprint/face template trong app/backend.
Không xem jailbreak/root detection là bằng chứng tuyệt đối; dùng như risk signal.
Chống overlay, screen capture và accessibility abuse ở các màn hình nhạy cảm trong phạm vi nền tảng cho phép.
Biometric UX không tự tạo phishing resistance. Phishing resistance đến từ cryptographic binding của FIDO credential với RP/origin.
Synced passkey hay device-bound credential?
Synced passkey
Ưu điểm: recovery và đổi máy dễ, UX tốt. Rủi ro phụ thuộc bảo vệ tài khoản cloud/passkey provider và quy trình khôi phục hệ sinh thái.
Device-bound passkey
Ưu điểm: private key không đồng bộ ra thiết bị khác, phù hợp một số risk model. Nhược điểm: đổi/mất máy khó hơn và cần enrollment/recovery mạnh.
Ngân hàng có thể hỗ trợ nhiều credential, phân loại capability và áp dụng policy theo risk. Không nên đoán rằng mọi passkey đều device-bound hoặc mọi synced passkey đều không phù hợp; quyết định phải dựa trên quy định, assurance và threat model.
Account recovery là bề mặt tấn công lớn nhất
Nếu attacker có thể bấm “Mất điện thoại” rồi nhận SMS để thêm passkey mới, toàn bộ phishing resistance bị hạ xuống mức SMS.
Recovery cần:
Inventory credential và revoke từng thiết bị.
Notification đến các kênh/thiết bị đã tin cậy.
Risk checks, cooling-off và temporary limits.
Step-up bằng credential còn lại, eKYC/reproofing hoặc assisted recovery theo risk.
Maker-checker cho case giá trị cao.
Không cho support bypass bằng câu hỏi bảo mật yếu.
Audit đầy đủ credential add/remove, SIM/email change và recovery decision.
Recovery strength phải tương xứng với authenticator mạnh nhất mà nó có thể thay thế.
Device enrollment và key lifecycle
Lưu:
Credential ID và public key.
User/account binding.
Credential type/capability khi xác định đáng tin cậy.
Created, last-used, revoked timestamps.
Enrollment method và policy version.
Friendly device label do người dùng đặt, nhưng không dùng label làm security evidence.
Cho phép user xem và thu hồi credentials. Sau revoke, session liên quan có thể cần invalidation tùy sự kiện.
Risk-based authentication
Signals có thể gồm:
New device or credential.
Impossible travel, IP reputation và velocity.
SIM/email vừa thay đổi.
Malware/root/hook signal.
Số tiền, beneficiary mới và hành vi bất thường.
Failed assertions, OTP retries và recovery activity.
Risk engine không được bí mật bypass user verification cho giao dịch rủi ro. Nó quyết định step-up, limit, review hoặc block theo policy có version và explainable reason.
Chống session hijacking sau xác thực
Passkey không ngăn attacker dùng access token/session đã bị đánh cắp sau login:
Token ngắn hạn và refresh rotation.
Ràng buộc token với app/device key khi kiến trúc hỗ trợ.
Secure cookie/keychain, TLS và certificate policy phù hợp.
Reauthentication cho hành động nhạy cảm.
Transaction nonce, idempotency key và anti-replay.
Phát hiện token reuse và revoke session.
Không log token hoặc challenge.
Authentication mạnh phải đi cùng session và transaction security.
Migration từ OTP sang Passkeys
Giai đoạn 1 — Làm sạch OTP
Chuẩn hóa expiry, rate limit, anti-replay, device binding và monitoring. Không migration trên nền OTP yếu.
Giai đoạn 2 — Đăng ký passkey tự nguyện
Cho người dùng thiết bị phù hợp tạo passkey sau strong reauthentication. Giữ OTP fallback nhưng cảnh báo và theo dõi downgrade.
Giai đoạn 3 — Passkey-first
Ưu tiên passkey cho login; OTP chỉ cho recovery hoặc thiết bị legacy. Step-up bằng passkey cho thay đổi nhạy cảm.
Giai đoạn 4 — Phishing-resistant by default
Hạn chế SMS ở risk tier cao, tăng transaction signing và recovery mạnh. Đo adoption, false rejection và fraud, không chỉ conversion.
API endpoints gợi ý
Challenge record dùng một lần, có purpose và expiry.
Không cho challenge login dùng để authorize payment.
Verify endpoint idempotent với challenge ID.
Rate limit và audit cả options lẫn verify.
Generic errors cho credential discovery.
Không lưu attestation/client data mà không có retention purpose.
Registration challenge bị reuse hoặc gắn sai account.
Origin/RP ID mismatch và look-alike domain.
User verification thiếu khi policy yêu cầu.
Duplicate credential và credential replacement attack.
Passkey synced sang máy mới; device-bound key bị mất.
Biometric/PIN failure và biometric enrollment thay đổi.
Session token bị đánh cắp sau passkey login.
Amount/beneficiary thay đổi sau transaction confirmation.
Recovery ngay sau SIM/email change.
Revoke credential khi còn active sessions.
Accessibility, account sharing và assisted recovery.
Checklist triển khai
Đã phân biệt SMS OTP, TOTP, transaction signing và FIDO assertion.
Passkey verification kiểm challenge, RP/origin, signature và user verification.
Private key và biometric data không rời authenticator.
Credential enrollment là sensitive operation có reauthentication/risk controls.
Login và transaction authorization dùng challenge/purpose riêng.
Giao dịch rủi ro hiển thị và ràng buộc amount/beneficiary.
Synced/device-bound policy được chọn có chủ đích.
Recovery không hạ bảo mật về SMS đơn lẻ.
Session/token có anti-theft và reauthentication controls.
Credential lifecycle, notification, revoke và audit hoạt động.
Kết luận
SMS OTP là bước khởi đầu phổ biến, Soft OTP giảm phụ thuộc nhà mạng, còn Smart OTP có thể tăng bảo vệ bằng device binding và transaction signing. FIDO2/passkeys đi xa hơn bằng public-key authentication gắn với đúng RP, nhờ đó chống phishing tốt hơn mã nhập tay.
Nhưng passkey không phải nút “bật sinh trắc học”. Một triển khai Mobile Banking an toàn phải thiết kế đồng thời credential enrollment, user verification, transaction intent, session security, recovery và migration.
Table of contents(29)
Codeplain text
1TOTP = Truncate(HMAC(secret, time_counter))
Codeplain text
1PENDING_ENROLLMENT -> ACTIVE -> SUSPENDED -> REVOKED2 -> COMPROMISED
Hướng dẫn xử lý transaction storm trong flash sale và quyết toán lương với RabbitMQ/Kafka, rate limiting, backpressure, circuit breaker, load shedding, idempotency và capacity planning.
Hướng dẫn tích hợp cổng thanh toán VNPay, ZaloPay, MoMo và Stripe: payment flow, chữ ký webhook/IPN, idempotency, retry, reconciliation, refund và vận hành production.
