问短信2FA的安全代码故意容易记住吗？

EN

我也注意到了这一点，我认为这是人类大脑将模式应用于随机噪声的趋势的结果。当特别地试图记住一个数字串时，这种情况似乎更常见。

大约85%的六位随机数中至少有一位重复数字，40%的人在彼此旁边有一个重复的顺序数字。(我很高兴在数学上得到纠正。)

这些键是使用标准TOTP算法生成的。本文总结了这个实现，表明没有任何努力来生成一个令人难忘的数字：

根据RFC 6238，参考执行情况如下：

• 生成一个键K，它是一个任意字节字符串，并与客户端安全地共享它。
• 商定一个T0，从TI开始计数时间步骤的Unix时间和间隔TI，它将用于计算计数器C的值(默认值是Unix时期为T0，30秒为TI)。
• 同意使用加密散列方法(默认为SHA-1)
• 同意一个标记长度，N(默认值为6)

尽管RFC 6238允许使用不同的参数，但验证器应用程序的Google实现不支持T0、TI值、散列方法和标记长度(与默认情况不同)。它还期望根据RFC 3548以基-32编码方式输入(或以QR码提供)K密钥。一旦商定了参数，令牌生成如下：

1. 计算C作为TI在T0之后经过的次数。
2. 用C作为消息，K作为密钥计算HMAC哈希H( HMAC算法在上一节中定义，但大多数密码库也支持它)。K应该按原样传递，C应该作为原始的64位无符号整数传递.
3. 取至少4个重要的H位作为偏移量，O。
4. 从O字节MSB开始，从H取4个字节，丢弃最重要的位，并将其余的存储为(无符号)32位整数，I。
5. 标记是基10中i的最低N位数。如果结果的数字小于N，则从左开始用零填充它。

服务器和客户端都计算令牌，然后服务器检查客户端提供的令牌是否与本地生成的令牌匹配。有些服务器允许在当前时间之前或之后生成代码，以便考虑到轻微的时钟偏差、网络延迟和用户延迟。

在我的手机上，我有来自不同公司的大约90个验证代码。其中62例为6位长。以下是每个数字的计数：

可能有点偏向1,8和9？几乎可以肯定的是，数据中只有噪声(62是一个小样本)。

两位数怎么样？

第一张图只是两位数边界上的两位数(即AABBCC)，所以我们期望每对在186个可能的数字位置上出现大约1.86次。第二种是任何位置(即XXX99X算作两位数)。我们预计每对在310次放置约3.1次。

似乎没有任何明显的倾斜，更多的两位数比非两位数显示的橙色。在后一种数据中，我们预计大约有31位数，我们得到27位数。这似乎是合理的。

当然，这并不排除其他“非随机”模式--但诚实地说，人类很可能正在寻找模式--看看这些数据，这些数据摘自我的2 2FA应用程序: 365 595,111 216,566 272,468 694,191 574,833 043。