我对 RSA SecurID 和类似的 2-factor 系统非常着迷。
我看过很多文章，包括这篇：https://security.stackexchange.com/questions/9584/can-the-numbers-on-rsa-securid-tokens-be-predicted
我的问题是，由于 RSA 的算法使用“种子”，因此生成的数字是“系列”。
如果我在服务器请求时在安全设备上生成了一个令牌，而不是使用该令牌我再次按下按钮以生成另一个令牌，该怎么办？ 这不会导致设备和服务器上运行的系列“不匹配”吗？
如果逻辑只依赖于时钟和设备序列号会更容易，但由于涉及到种子和随机数，我想知道如果你跳过一个或两个令牌会发生什么？
谢谢。
【问题讨论】：
标签： encryption random cryptography rsa securid
据我了解，SecurID tokens 不使用“滚动计数器”——令牌仅由设备序列和当前时间生成。另外：在我见过的 RSA SecurID 令牌中（当然是有限的），用户没有按下按钮来生成令牌；相反，令牌在屏幕上始终可见。因此生成的令牌不会（按顺序）与服务器不同步，除了令牌端时钟漂移的可能性（通常服务器使用 NTP，因此它们的时钟漂移可以忽略不计）。
但是，时钟漂移问题的典型解决方案是在服务器上存储一个“漂移”参数，基于每个令牌。这个漂移参数可以手动更新（为了最大的安全性，但也是最大的痛苦），或者可以检查服务器端的周围间隔。例如，如果我现在登录，您可能会检查服务器当前的 60 秒间隔、上一个和下一个是否有效，如果上一个/下一个有效，则存储该偏移作为令牌。
另一方面，有一种算法存在您所描述的问题：HMAC-based One-time Password Algorithm。它使用一个滚动计数器，应该在服务器和令牌上同步。因此，如果您有一个基于 HOTP 的身份验证器，并且您多次按下令牌生成按钮，您将导致它不同步，并且需要服务器管理员手动干预。
可以像上面那样制定一个类似的解决方案：检查计数器的下几个值，比如 counter+1、counter+2、counter+3 等，并将其存储为“漂移”参数。根据检查的距离，如果反复按下，令牌最终可能会不同步。
解决问题的 HOTP 变体是time-baesd version，它使用“时间计数器”而不是实际计数器。这就是 Google Authenticator 使用的。在这里，您仍然有时钟漂移问题，解决方案与上述相同。
【讨论】：
如果您对 OTP 系统着迷，那么您应该阅读描述基于 HMAC 的 OTP 算法的 RFC 4226 和描述基于时间的 OTP 算法的 RFC 6238，因为大多数可用的 OTP 解决方案都使用这两种算法今天。
如果您也对两因素身份验证领域的最新发展感兴趣，那么您应该访问FIDO Alliance 的网站并查看他们的规格。
【讨论】：