移动APP中FIDO2与推送触发生物识别的MFA安全及实现差异问询

一、安全性差异 #

推送触发生物识别 #

• 依赖推送通道安全：认证流程始于服务器推送通知，若推送通道（如APNs/FCM）被劫持篡改，攻击者可伪造通知诱导用户完成生物识别，进而授权恶意操作。
• 本地验证风险：生物识别仅在设备本地完成，验证通过后由APP向服务器发送授权信号。若设备被Root/越狱，本地生物识别逻辑可能被绕过，授权信号也存在被伪造的可能。
• 凭证绑定弱：服务器仅校验APP发送的授权凭证，未与设备身份强绑定，存在凭证被重放或伪造的风险。

FIDO2 #

• 公钥加密核心：基于公钥密码学，设备本地生成公私钥对，公钥存储在服务器，私钥安全存于设备的安全元件（SE/TEE）中，私钥永远不会离开设备，从根源避免密钥泄露。
• 挑战响应机制：认证时服务器发送随机挑战，设备用私钥签名后返回，服务器通过公钥验证签名有效性，天然抵御重放攻击。
• 硬件级安全：私钥存储在硬件安全区域，即使设备被Root/越狱，攻击者也无法提取私钥；生物识别/PIN仅作为解锁私钥的凭证，而非直接认证依据，安全等级更高。

二、实现层面差异 #

推送触发生物识别 #

• 流程逻辑：
  • 服务器发起认证请求，向目标设备推送通知
  • 用户点击通知，触发设备本地生物识别验证
  • 验证通过后，APP向服务器发送预定义授权凭证
  • 服务器校验凭证合法性，完成认证
• 依赖组件：推送服务（APNs/FCM）、平台生物识别API（iOS Face ID/Touch ID、Android Biometric API）、APP本地业务逻辑
• 开发成本：较低，只需集成推送SDK和生物识别API，处理好本地验证与服务器授权的衔接即可
• 兼容性：覆盖绝大多数现代移动设备，无需额外硬件支持

FIDO2 #

• 流程逻辑：
  • 服务器发起认证请求，生成随机挑战值
  • APP调用FIDO2客户端框架，将挑战值传递给设备安全元件
  • 设备触发生物识别/PIN验证，解锁私钥
  • 私钥对挑战值签名，APP将签名结果返回服务器
  • 服务器用存储的公钥验证签名，完成认证
• 依赖组件：FIDO2客户端框架（iOS WebAuthn、Android FIDO2 API）、设备安全元件（SE/TEE）、服务器端FIDO2协议实现（公钥存储、挑战生成、签名校验）
• 开发成本：较高，需服务器端完整实现FIDO2协议，客户端适配不同平台的FIDO2接口，同时要考虑不同设备安全元件的兼容性
• 兼容性：需设备支持FIDO2标准，主流新设备均支持，但部分老旧设备可能无法适配

内容的提问来源于stack exchange，提问作者geolykos