一文搞懂一次性密码：OTP、HOTP、TOTP详解

1. 背景：为何需要 OTP？

静态密码（如固定账号密码）是早期身份验证的主流方式，但存在三大核心缺陷：

• 泄露风险高：易通过钓鱼、木马、数据库泄露等方式被窃取，且窃取后可长期复用；

• 暴力破解易：固定密码长度、复杂度有限，攻击者可通过字典攻击、暴力枚举破解；

• 场景适配差：金融交易、企业登录等高频高安全场景，需更动态的验证手段。

为解决上述问题，OTP（One-Time Password）应运而生，1984 年由 RSA 实验室首次提出，核心定位是 “单次有效、用完即废” 的动态密码，通过 “动态因子 + 共享密钥” 打破静态密码的固定性，成为多因素认证（MFA）的核心组件。

2. 原理：如何生成 OTP？

OTP 的生成遵循 “共享密钥 + 动态因子” 的核心逻辑，具体步骤如下：

1. 初始化阶段：服务器与客户端（如 APP、硬件令牌）预先协商并存储一个 “共享密钥（Secret Key）”，该密钥仅双方知晓，不通过网络传输；
2. 动态因子获取：客户端获取实时动态因子（可分为事件因子、时间因子、挑战因子，对应不同 OTP 实现）；
3. 哈希计算：通过 HMAC（哈希消息认证码）算法（如 SHA-1、SHA-256），将 “共享密钥 + 动态因子” 组合计算为固定长度的哈希值；
4. 密码转换：对哈希值进行截取（如取哈希值后 6 位）、进制转换（如从十六进制转十进制），最终生成 6-8 位的数字 OTP。

3. 应用场景：OTP 的核心使用领域

OTP 作为动态验证的基础，覆盖全场景高安全需求，典型场景包括：

• 登录保护：网站 / APP 的二次验证（如电商平台登录、企业 OA 系统登录）；

• 交易确认：金融转账、支付扣款、理财产品赎回等资金操作的验证；

• 设备绑定：新设备登录、账号异地登录时的身份确认；

• 权限管控：服务器登录、数据库操作、工业控制系统等高危操作的授权。

4. 交互流程：OTP 的完整使用链路

以 “用户登录某金融 APP” 为例，OTP 的标准交互流程如下：

1. 初始化（前置步骤）：用户在 APP 注册时，系统生成 “共享密钥”，通过二维码 / 短信等方式同步至用户客户端（如手机验证 APP）；
2. 触发验证：用户输入账号密码后，APP 提示 “需 OTP 验证”，向服务器发起验证请求；
3. 生成 OTP：用户客户端（如验证 APP）获取动态因子，结合共享密钥生成 OTP，展示给用户；
4. 提交验证：用户将 OTP 输入 APP，APP 将 OTP 发送至服务器；
5. 服务器校验：服务器使用相同的 “共享密钥 + 动态因子” 生成 OTP，与用户提交的 OTP 比对；
6. 结果反馈：若一致则验证通过，允许登录；若不一致则提示 “OTP 错误”，需重新生成提交。

二、HOTP（基于 HMAC 的一次性密码）：事件驱动的实现

1. 背景：为何需要 HOTP？

OTP 的 “动态因子” 需适配不同场景：部分场景（如硬件令牌、工业设备登录）无法依赖精准时间同步（如工业环境时间易偏差），且需 “每用一次失效” 的稳定逻辑，因此诞生了以 “事件计数器” 为动态因子的 HOTP（HMAC-Based OTP），1998 年由 RFC 4226 标准正式定义，核心解决 “无时间依赖的动态验证” 需求。

2. 原理：事件计数器如何驱动 HOTP？

HOTP 是 OTP 的 “事件驱动型” 实现，核心是用 “验证次数计数器” 替代灵活因子，原理步骤：

1. 核心参数约定：服务器与客户端预先约定 3 个关键参数 —— 共享密钥（Secret Key）、初始计数器值（默认从 0 开始）、哈希算法（默认 SHA-1）；
2. 计数器同步：每次验证通过后，服务器与客户端的计数器 “同步递增 1”，确保下次生成 OTP 时使用相同的计数器值；
3. HOTP 生成公式：

HOTP = Truncate(HMAC-SHA-1(Secret Key, Counter)) → 6-8位数字

其中 “Truncate” 是截取操作：取 HMAC 哈希值的后 4 字节，通过位运算转换为十进制数字，再取最后 6-8 位。

3. 应用场景：HOTP 的适配领域

HOTP 因 “不依赖时间、依赖计数器同步”，适合以下场景：

• 硬件令牌：银行 U 盾、企业员工身份令牌（如 RSA SecurID 早期版本），设备内置计数器，按一次生成一个 HOTP；

• 固定设备验证：工业控制系统、机房服务器本地登录，设备位置固定，计数器同步稳定；

• 低网络场景：无网络或弱网络环境（如离线 POS 机），无需实时时间同步，仅需本地计数器递增。

4. 交互流程：HOTP 的完整验证链路

以 “企业员工用硬件令牌登录 OA 系统” 为例，流程如下：

1. 初始化配置：企业为员工发放硬件令牌时，在令牌中写入 “共享密钥” 和 “初始计数器（0）”，同时在 OA 服务器中存储相同的密钥和计数器；
2. 触发验证：员工输入 OA 账号密码后，系统提示 “输入硬件令牌 OTP”；
3. 生成 HOTP：员工按下硬件令牌按钮，令牌读取当前计数器值（如首次使用为 0），结合共享密钥生成 6 位 HOTP，显示在令牌屏幕上；
4. 提交与校验：员工输入 HOTP 至 OA 系统，系统用 “当前计数器（0）+ 共享密钥” 生成 HOTP，与输入值比对；
5. 计数器同步：若比对一致，OA 服务器将计数器更新为 1，同时硬件令牌下次生成 HOTP 时，计数器自动递增为 1；
6. 异常处理：若因网络延迟导致验证失败（如 HOTP 已生成但未及时提交），服务器允许 “计数器向后偏移 5 步”（即校验当前计数器 ±5 范围内的 HOTP），避免同步失效。

三、TOTP（基于时间的一次性密码）：时间驱动的优化

1. 背景：为何需要 TOTP？

HOTP 依赖硬件令牌和计数器同步，在移动端普及后，存在两大局限：

• 硬件依赖重：需额外携带硬件令牌，不适配手机等移动设备；

• 同步成本高：若客户端丢失（如令牌损坏），需重新配置计数器，操作繁琐。

为适配移动端便捷性需求，TOTP（Time-Based OTP）于 2011 年由 RFC 6238 标准定义，核心是将 HOTP 的 “事件计数器” 替换为 “时间计数器”，无需硬件、依赖时间同步，成为当前移动端验证的主流方案。

2. 原理：时间窗口如何驱动 TOTP？

TOTP 是 OTP 的 “时间驱动型” 实现，本质是 “时间化的 HOTP”，原理步骤：

1. 核心参数约定：服务器与客户端（如手机 APP）约定 3 个参数 —— 共享密钥（Secret Key）、时间窗口（默认 30 秒，可配置为 60 秒）、哈希算法（SHA-1）；
2. 时间计数器计算：客户端获取当前 Unix 时间戳（如 1718000000 秒），计算 “时间戳 ÷ 时间窗口” 的整数结果，即 “时间计数器”（如 1718000000 ÷ 30 ≈ 57266666）；
3. TOTP 生成公式：与 HOTP 一致，即 TOTP = Truncate(HMAC-SHA-1(Secret Key, 时间计数器)) → 6位数字，且在当前时间窗口内，时间计数器不变，TOTP 保持固定；
4. 时间偏差容错：服务器与客户端时间可能存在微小偏差，因此服务器会校验 “当前时间计数器 ±1” 对应的 TOTP（如 30 秒窗口下，校验当前、前 30 秒、后 30 秒的 TOTP）。

3. 应用场景：TOTP 的主流使用领域

TOTP 因 “无硬件依赖、便捷性高”，成为移动端及互联网场景的首选，典型场景：

• 移动端验证 APP：Google Authenticator、Microsoft Authenticator、微信安全中心、支付宝身份验证；

• 互联网平台登录：GitHub、AWS、阿里云、腾讯云等平台的二次验证，防止账号被盗；

• 金融移动端操作：银行 APP 转账、证券账户交易、支付平台扣款时的动态验证码；

• 轻量级企业场景：小型企业员工登录 CRM、协作工具（如飞书、钉钉）的二次验证，无需部署硬件令牌。

4. 交互流程：TOTP 的完整验证链路

以 “用户用 Google Authenticator 验证 GitHub 登录” 为例，流程如下：

a.初始化绑定：

• 用户在 GitHub “安全设置” 中开启 “2FA（双因素认证）”，GitHub 生成含 “共享密钥” 的二维码；
• 用户打开 Google Authenticator，扫描二维码，APP 存储共享密钥，并约定 “30 秒时间窗口”；

b.触发验证：

• 用户输入 GitHub 账号密码后，系统提示 “输入 Authenticator 中的 6 位验证码”；

c.生成 TOTP：

• Google Authenticator 获取当前时间戳（如 1718000010 秒），计算时间计数器（1718000010 ÷ 30 ≈ 57266667）；
• 结合共享密钥生成 6 位 TOTP（如 123456），并显示倒计时（如剩余 15 秒，提示 “即将更新”）；

d.提交与校验：

• 用户输入 TOTP（123456）至 GitHub，GitHub 获取当前时间计数器（57266667），结合存储的共享密钥生成 TOTP；
• GitHub 同时校验 “57266666（前 30 秒）、57266667（当前）、57266668（后 30 秒）” 对应的 TOTP，若用户输入的 123456 匹配，验证通过；

e.失效与更新：

• 30 秒时间窗口结束后，时间计数器自动递增为 57266668，Google Authenticator 生成新的 TOTP（如 654321），旧 TOTP 失效。

四、OTP、HOTP、TOTP 核心差异对比

对比维度	OTP（大类）	HOTP（事件驱动）	TOTP（时间驱动）
背景定位	解决静态密码缺陷，动态验证基础	适配无时间依赖场景，硬件优先	适配移动端，无硬件便捷验证
核心原理	共享密钥 + 动态因子（通用）	共享密钥 + 事件计数器	共享密钥 + 时间计数器（时间窗口）
关键依赖	动态因子的有效性	服务器 - 客户端计数器同步	服务器 - 客户端时间同步（±30 秒）
应用场景	全场景高安全验证	硬件令牌、工业设备、离线场景	移动端 APP、互联网登录、在线交易
交互核心步骤	初始化密钥→生成 OTP→校验→同步	初始化密钥 + 计数器→生成 OTP→校验→计数器 + 1	初始化密钥 + 时间窗口→生成 OTP→校验→时间窗口更新
失效机制	单次使用后失效	使用后计数器递增，旧值失效	时间窗口结束，自动失效

五、总结：如何选择 OTP 方案？

1. 场景优先：离线、硬件依赖、无时间同步场景→选 HOTP；移动端、在线、便捷性需求场景→选 TOTP；
2. 安全平衡：两者均基于 HMAC 算法，安全级别相近，HOTP 需防范计数器不同步，TOTP 需确保时间偏差在 ±30 秒内；
3. 成本考量：HOTP 需硬件令牌（如 U 盾），成本较高；TOTP 仅需手机 APP，零硬件成本，适合大规模普及。

OTP 体系的核心价值，在于用 “动态性” 弥补静态密码的安全短板，而 HOTP 与 TOTP 的分化，正是对不同场景需求的精准适配。