MFA 与一次性密码概述
多因素认证(Multi-Factor Authentication,MFA)通过要求用户提供两个或以上相互独立的认证要素来证明身份,从而在密码泄露时提供纵深防御。本章聚焦工程实践中最常见的第二因素形态——一次性密码(One-Time Password,OTP),重点讲解 HOTP 与 TOTP 两个算法。
什么是 MFA
单一密码认证的核心弱点在于:密码是静态且可复制的凭据。一旦被撞库、钓鱼、数据库泄露或键盘记录窃取,攻击者即可无限次重放。MFA 的思路是叠加来自不同"类别"的认证要素,使得攻击者必须同时攻破多个独立信道才能成功。
三类认证要素
认证要素传统上分为三类,MFA 要求所用要素分属不同类别才算真正的"多因素"(两个密码不构成 MFA):
| 类别 | 英文 | 含义 | 典型实例 |
|---|---|---|---|
| 所知(Knowledge) | something you know | 用户记忆的秘密 | 密码、PIN、安全问题 |
| 所有(Possession) | something you have | 用户持有的设备/物件 | TOTP 验证器 App、硬件令牌、手机(短信/推送)、FIDO 安全密钥 |
| 所是(Inherence) | something you are | 用户的生物特征 | 指纹、人脸、虹膜、声纹 |
提示
"所知 + 所有"是当前最主流的 MFA 组合:密码(所知)+ TOTP 验证器 App(所有)。本章讲的 OTP 属于"所有"类别——它证明用户持有那个存有共享密钥的设备。
OTP 解决什么问题
一次性密码(OTP)是只能使用一次、且很快失效的动态口令。相比静态密码,它的价值在于:
- 抗重放:每个 OTP 仅在极短窗口内有效(TOTP 通常 30 秒),即使被截获,攻击者的重用窗口也极小。
- 不可预测:OTP 由密码学算法基于共享密钥生成,攻击者无法从历史 OTP 推算下一个。
- 离线生成:基于本地共享密钥计算,无需网络往返,不依赖短信通道(短信 OTP 存在 SIM 劫持等风险)。
OTP 有两种标准算法,均由 IETF 定义,共享同一套动态截断核心:
- HOTP(HMAC-based One-Time Password,RFC 4226):基于递增计数器。
- TOTP(Time-based One-Time Password,RFC 6238):基于当前时间,是 HOTP 的时间化变体。
HOTP 与 TOTP 的关系与区别
TOTP 并非独立算法,而是把 HOTP 的"计数器"替换为"时间步长"。二者关系可概括为:
TOTP(K) = HOTP(K, T)，其中 T = floor((当前 Unix 时间 - T0) / period)
也就是说,HOTP 是基础,TOTP 是在其上把移动因子从"计数器"改为"时间片编号"。
| 维度 | HOTP(RFC 4226) | TOTP(RFC 6238) |
|---|---|---|
| 移动因子 | 事件计数器 counter | 时间步长 T |
| 何时变化 | 每次生成时计数器 +1 | 每个时间步(默认 30 秒)自动变化 |
| 服务端状态 | 需持久化并同步计数器 | 只需记录密钥,无需存计数器 |
| 失步风险 | 客户端与服务端计数器可能不同步,需前向查找窗口 | 只受时钟偏移影响 |
| 有效期 | 直到下次使用前一直有效 | 仅当前时间步(+容错窗口)有效 |
| 典型用途 | 硬件令牌按键生成、离线场景 | 验证器 App、绝大多数在线 MFA |
注意
HOTP 的计数器同步是工程难点:用户可能误触令牌导致计数器超前,服务端需设置"前向查找窗口"(look-ahead window)。TOTP 用时间取代计数器,天然规避了这个问题,因此在线服务几乎都用 TOTP。
TOTP 在实践中的地位
TOTP 是目前部署最广的软件第二因素:
- 验证器 App:Google Authenticator、Microsoft Authenticator、Authy、1Password、FreeOTP 等都实现 TOTP,通过扫描二维码导入共享密钥。
- 登录集成:在 OIDC(OpenID Connect)/ SAML 的企业登录流程里,TOTP 常作为密码之后的第二步验证(step-up / 二次验证),由 IdP(身份提供方)在完成第一因素后触发。
- 标准化与互操作:因为算法与
otpauth://URI 都有公开标准,任意验证器 App 与任意服务端可互通,无需绑定特定厂商。
与 WebAuthn 的对比
TOTP 部署简单、体验熟悉,但它有一个根本局限:不抗钓鱼。TOTP 码与访问的域名无绑定关系,用户会把在钓鱼站看到的 6 位码原样输入,攻击者可实时中继(real-time phishing / MITM)。WebAuthn / FIDO2 用公钥密码学并把凭据与来源域名(origin)绑定,从协议层面阻断钓鱼。
| 特性 | TOTP | WebAuthn / Passkey |
|---|---|---|
| 抗钓鱼 | 否(码可被中继) | 是(凭据绑定 origin) |
| 共享密钥 | 有(服务端也存密钥,泄露即可克隆) | 无(私钥不出设备) |
| 抗服务端泄露 | 弱 | 强(服务端只存公钥) |
| 用户操作 | 手动输入 6 位码 | 生物识别/PIN 一触 |
| 部署成本 | 低 | 中(需浏览器/平台支持) |
| 离线可用 | 是 | 视认证器而定 |
提示
可将 TOTP 视为"比密码强、比 WebAuthn 弱"的中间层。对安全要求高的场景,应优先推进 WebAuthn(见 ../webauthn/);TOTP 适合作为广覆盖的基线第二因素,或 WebAuthn 尚不可用时的回退方案。
适用场景
- 推荐使用 TOTP:面向公众的 SaaS 需要一个零硬件成本、跨平台的第二因素;企业为存量账户快速铺开 MFA;作为 WebAuthn 的降级回退。
- 推荐使用 HOTP:发放专用硬件令牌、无稳定时钟的离线设备。
- 谨慎/不推荐:仅用短信 OTP 作为高价值账户的唯一第二因素(SIM 劫持、SS7 攻击风险);对抗钓鱼有硬性要求的场景应上 WebAuthn。
本章导航
- HOTP / TOTP 算法详解 —— 共享密钥、HMAC 动态截断、TOTP 时间步长、验证窗口与完整 JS 示例。
- otpauth URI 与参数参考 ——
otpauth://URI 格式、参数默认值、二维码约定、验证器兼容性与排错速查。