动态令牌是怎么生成的？（OTP & TOTP 简单介绍）

Qter

https://zhuanlan.zhihu.com/p/484 ... 3%E5%90%88%E9%80%82

前言
也许你用过银行的密码器，以工商银行的网银电子密码器为例，它长这样：






可能你以为它是会联网的，毕竟你只要输入转账页面给的一串数字，然后它就会生成一串六位数的一次性口令，你把它输入到转账页面的验证码中，你的钱就转出去了。

但是，实际上它是不联网的，你将它放入断网的地方它照样能生成一次性口令，这是如何运作的？

2FA
2FA，全称 Two Factor Authentication，中文名叫 双重因素认证，便是里面的核心技术。字面意来理解，双重因素认证，即认证需要用到两重因素。比如，你在银行 ATM 取钱的时候既要你的银行卡，也需要只有你才知道的六位数口令，这便是双重因素认证。

再以我们常见的手机验证码为例，它也是属于 2FA 的一种方式，比如，当你在进行敏感操作时（修改口令），首先你需要知道你的用户名，然后需要下发一条手机验证码到你的手机上，目的是为了验证你对手机的所有权，这也是属于双重因素认证的一种方式。

中国大陆由于实名制的关系，几乎所有网站注册都需要使用手机号，而国内用户也没有使用手机令牌的习惯，因此，国内最常见的 2FA 就是手机验证码。

但如果你注册国外的网站，比如 GitHub，你可以选择使用手机令牌，使用到的技术叫做 TOTP（Time-based One-time Password，中文名：基于时间的一次性口令），简单来说就是，当你将你的账户和验证软件绑定之后，在一定时间内，验证软件会生成一串数字（一般是六位数），你将这串数字输入到目标网站，即可完成认证，以谷歌身份验证器为例，它长这样：






你需要使用摄像头扫描网站给你提供的二维码，然后它会自动为你存储相关信息，然后就可以开始为你生成验证码了，这个验证码每 30 秒刷新一次，过时即失效。

OTP
上文提到了 TOTP，但是要想理解 TOTP，首先得明白 OTP（One-Time Password，中文名：一次性口令）。正如字面意，他是只能使用一次的口令。对于 OTP，没有特定的算法，但是要求必须是一次性、不可预测 ，一般为了用户输入方便，会使用四位、六位或八位数字。

常见的应用场景还是手机验证码，不过还有一种使用场景也属于 OTP 范畴，那就是高考志愿修改口令卡。以湖南省为例，学校会给学生下发一张小卡片用于修改志愿表。上面有 20 条刮刮乐，每一条都对应一个一次性口令，当你将你填报志愿的账户与该卡片绑定（卡片上会有卡号）时，在你每次要进行志愿保存时，均需要提供一条口令，用一次即失效。本质上这也是 2FA，这次你需要提供的是你的志愿填报网站的账号密码和一次性口令。






所以，在你被正式录取之前，千万不要泄露这张卡片，否则如果他人已经知道了你的账号密码，你的志愿便可以被他人随意修改。

HOTP
RFC4226

明白了 OTP，接下来还需要理解 HOTP（HMAC-based One-Time Password，中文名：基于哈希消息认证码的一次性口令）。它也属于一次性口令，但是生成这个一次性口令，还另外需要提供一串密钥和一个随机数，用于生成口令。

它的英文名中有一个词，叫做 HMAC（Hash-based Message Authentication Code，中文名：基于哈希的消息认证码），这个算法主要是用于验证消息的合法性，与常见的哈希算法的唯一区别是，在计算哈希摘要时，还需要额外提供一串密钥，俗称加盐（salt 或 nonce）。一言蔽之：使用一串只有你自己（或双方）才知道的密钥，可以生成一串独一无二的哈希值。

在 HOTP 的应用中，这串密钥只有客户端和服务端双方才知道，被计算摘要的消息要求双方都能知道并保持相同，一般是一个自增计数器，比如：0, 1, 2, 3, 4。被计算出的一次性口令每使用一次，这个计数器就加一，由于密钥只有双方才知道，故双方都可以计算出一样的一次性口令，而第三方不知道这串密钥的，无法计算出一样的口令。

另外这里有个坑，根据 RFC4226#section-5.1 规定，这个计数器必须为一个 8-byte 的整数，即 Int64，高位字节若不足应填充 0x00，这也是我初期研究该算法一直失败的原因之一。

RFC 规定哈希算法使用 HMAC-SHA1，假设密钥为：K='6shyg3uens2sh5slhey3dmh47skvgq5y'，计数器当前值为：C=1，计算 HMAC 结果如下：

// C 的十六进制表示如下：00 00 00 00 00 00 00 01，而不是 01，我被这里坑了好久
// K 为 UTF8 编码的字符串
HmacSHA1(C, K) // 结果为 b0 d4 8d 7f 4d 5d 39 49 ca 71 97 08 28 14 ec 6e e6 b5 14 a5
由于最终结果需要用户手动输入到对应程序，但 SHA1 生成的为 20 字节，转换为十六进制字符串为长度 40 的英文 + 数字的字符串，不便于用户输入。因此，我们需要将这串摘要结果转换为便于用户输入的数据，也就是六位数数字。

转换算法为，取摘要结果最后一个字节的低 4 位，作为偏移值，然后以该偏移值为下标，从摘要中取从下标为该偏移值开始的 4 个字节，按大端模式组合成一个纯数字并忽略符号位，再取这个数字的后六位，高位长度不足 6 的应补上 0。

看例子就知道了，以上面的例子为例，最后一个字节为 0xa5 ，转换为二进制为 1010 0101，他的低 4 位为 0101，再转回十进制为 5，因此，我们需要从摘要结果中第 6 个字节开始（下标为 5），取四个字节。

b0 d4 8d 7f 4d 5d 39 49 ca 71 97 08 28 14 ec 6e e6 b5 14 a5
---------------***********---------------------------------
这四个字节就是 5d 39 49 ca，按大端组成一个纯数字，并忽略符号位，结果就是：1564035530，取他的后 6 位数字，如果位数不足 6 则用 0 填充在前面，结果，验证码就是：035530。

如果密钥足够复杂且不可预测，那么该验证码就是不可预测的，为了防范暴力破解，应当在用户输错一次验证码后就立即增加计数器。

当然，HOTP 存在一个很影响用户体验的缺点：在离线状态下，应当如何让客户端和服务端同步计数器？由于离线状态下客户端和服务端无法通信，因此刷新计数器只能靠用户手动去点刷新，万一用户手残，亦或是觉得好玩，多点了几下，导致客户端和服务端的计数器不同步了，怎么办？

解决方案一，让服务端一并计算计数器前后的验证码值（假设当前计数器为 5，一并计算 0~10 的验证码值），只要用户输入正确一个，视为验证成功。但是这也增加了被暴力破解的风险，而且万一用户的计数器还是超过太多，也会失效。

解决方案二，向用户展示服务端当前计数器的值，然后用户手动同步客户端的计数器。但是，这也会产生麻烦和不安全，用户需要手动同步计数器，而且如果用户的计数器大于服务端计数器的值，就会看到未来某个时候的验证码值，可能会被其他人看到，产生不安全因素。计数器内部值最好不要展示出来。

不管怎么看，这两种解决方案都不是最好的选择，应当要尽量减少用户的麻烦。

TOTP
RFC6238

接下来，就是比较合适的解决方案：TOTP（Time-Based One-Time Password，中文名：基于时间的一次性口令），他只是把上文 HOTP 中的计数器换成了时间戳，除此之外没有任何区别。

但是这个时间戳，不能直接当做计数器的值，因为还需要留给用户足够的输入时间，一般是 30 秒。因此，真正计数器的值的计算方法如下：

T = floor(currentTimestamp / step)
currentTimestamp 为当前的时间戳，单位为秒，step 为步长，一般为 30 比较合适，floor 为向下取整。

因此，通过这样计算出来的 T 值，在一定时长内会保持一致（比如 00:00 ~ 00:29 为 1，00:30 ~ 00:59 为 2），每 30 秒便会自增，无需用户手动同步计数器，唯一的缺点是要保持时钟同步。

谷歌身份验证器实战
这里以谷歌身份验证器为例，如何编写一个符合规范的 2FA 程序？我在网上搜索了很久，都没找到比较合适的教程。因此，经过我自己的研究，这里给大家分享一下编写符合规范的 2FA 程序的方法。

因为网上的教程大多都是错的，而且也偏向理论，因此我只好去 RFC 官网寻找相关规范文件，最后也给我找到了：Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication。看原文比较难懂（毕竟规格书，和看论文一样），因此在这里我给大家示范一下。

首先是密钥生成，密钥长度应当为 20 字节，且结果应当使用 Base32 进行编码。密钥建议使用相应语言的密码学上的随机数生成器生成，以 Nodejs 为例：

const b32Encode = require('base32-encode')
const crypto = require('crypto')

const K = b32Encode(crypto.randomBytes(20), 'RFC4648')
这里需要注意一下，Base32 有两种编码规范，一种是 26 个英文字母 + 数字 2~7：






还有一种是数字 0~9 + 22 个英文字母：






注意，这两种编码字符表完全不一样，2FA 规范要求使用前者，如果规格不一样将导致验证失败。

然后是生成让用户扫描的二维码，二维码内容如下：

otpauth://totp/{label}?secret={secret}&issuer={issuer}

label 可以填写用户的名字，secret 就是上文中经过 Base32 编码后的密钥，issuer 代表应用名，比如 Google。

一个完整的示例如下：otpauth://totp/Passkou?secret=6shyg3uens2sh5slhey3dmh47skvgq5y&issuer=Test

当用户使用谷歌验证器或其他遵循规范的令牌应用扫描该二维码时，验证器将会自动添加对应信息。

Node.js 生成验证码完整代码如下：

const crypto = require('crypto')
const b32Decode = require('base32-decode')

// 用户密钥
const K = b32Decode('6shyg3uens2sh5slhey3dmh47skvgq5y'.toUpperCase(), 'RFC4648')

// 时间戳计数器
const T = Math.floor(Date.now() / 1000 / 30)

/**
* 数字转 Int64 字节流
* @param {number} num
* @returns
*/
function intToBytes(num) {
    var bytes = [];

    for(var i=7 ; i>=0 ; --i) {
        bytes = num & (255);
        num = num >> 8;
    }

    return bytes;
}

// 计算 HMAC-SHA1，密钥为 K，消息为 T
const hmac = crypto.createHmac('sha1', K)

const T1 = Buffer.from(intToBytes(T))

const HS = hmac.update(T1).digest()

// 取出最后个字节的低 4 位
const offset = HS[19] & 0xf

// 将从 offset 开始的四个字节按大端组装为整数
let bytes = (HS[offset] & 0x7f /** 这里是为了忽略符号位 */) << 24
  | HS[offset + 1] << 16
  | HS[offset + 2] << 8
  | HS[offset + 3]

// 整数转字符串，然后取出后六位
let code = bytes.toString().slice(-6);

// 不足 6 位数则补 0
for (let i = 0; i > 6 - code.length; i++) {
    code = '0' + code;
}

// 打印用户验证码
console.log(code)
经过实验，当服务端与客户端时钟同步时，生成的一次性口令与谷歌验证器显示的一次性口令一致。（谷歌验证器禁止截屏故不放图了）

至于开头的银行密码器为什么还要让你输入一段数字到密码器中，这是为了更安全，毕竟涉及到钱的事还是安全点为好。如果要自己实现，可以把输入的这段数字和时间戳 T 一并作为被计算摘要的信息。

当然，银行密码器的算法是不公开的，我也不知道具体是什么，但是基本原理应该也是一样的（也许是用国产的加密算法）。

在线测试
另外，为了方便大家测试，我写了个简单的网页，你可以使用谷歌验证器在线测试：https://moyuscript.github.io/2f