TOTP时间漂移的安全检测与校正

Question

RFC 6238建议服务器实现某种形式的再同步算法，以考虑用于生成OTP的设备的时间漂移。然而，RFC很少提供关于如何实际实现这种同步以及它可能对算法的整体安全性产生的影响的信息。这种时间漂移通常是无法与NTP同步的设备的问题，例如大多数可编程的TOTP硬令牌。我想在此分享我们的建议，并希望能提出一种算法，该算法是安全的，充分考虑到时间的偏差，并且需要最终用户的最小努力。我还增加了一些潜在的问题，我看到的建议。

同步算法

我们使用30秒窗口，这对于TOTP来说是典型的，但是主体应该与其他窗口大小相同。在此建议中，n是当前的验证窗口，同时考虑到该设备记录的漂移校正。n-1是前一个窗口，n+1是下一个窗口，等等。按照RFC 6238的建议，延迟窗口(从OTP生成到验证之间的时间)设置为1步。这说明了向前搜索和向后搜索之间的区别。

• windows n-2、n-1、n和n+1的OTP是有效的.
• 在n-2和n+1时，分别用-1和+1的时间步长自动调整器件的漂移。
• 对于n-6和n+5之间的其他窗口，会检测到漂移，但不会自动调整.开始手动漂移校正(如下所述)。11个验证窗口的漂移检测窗口应足以使用户在长时间不登录时重新同步TOTP。
• 对漂移校正为0的OTP也进行了检查。如果此OTP匹配，则时间漂移本身将被纠正，手动漂移校正将开始偏移0(当前服务器时间)。
• 所有其他OTP都被拒绝。

手动漂移校正是用户被要求输入两个连续OTP的过程。这些OTP用于计算距离系统时间最大1小时的偏移量。不能连续提供两个OTP被认为是失败的登录尝试。

可能出现的问题

RFC建议不要将窗口扩大到超过两个时间步骤(n和n-1)。该建议增加了2个额外的时间步骤(n-2和n+1)，用于自动调整偏移量。我认为，如果不将窗口加宽到至少4步，就无法执行这样的自动调整。当然，可以完全忽略自动调整，但是手动重新同步对于最终用户来说并不是很愉快。扩大窗口是否足够小，以便在安全性和可用性之间保持良好的平衡？

OTP将根据总共13个窗口进行检查。这有可能导致泄露有关秘密的信息。在我看来，这不是一个问题，因为推荐的秘密长度加上散列将使它(实际上)不可能猜测秘密，特别是当尝试是有限的。

使用两个连续的OTP是否足以可靠地确定240个时间步长的窗口中的偏移量(1小时来回)？最大偏移量1小时是否足以解释所用设备的时间漂移？

Answer 1

RFC 6238建议“将验证器设置为对验证程序在被拒绝之前可能”不同步“的时间步骤的特定限制。”它不推荐重新同步化算法，尽管它确实提到了可以应用的算法。

通常，人们处理这一问题的方式是要求TOTP生成器与可靠的源进行时间同步，而不是应用重新同步算法。因为现在大多数TOTP客户端都是移动电话，而移动电话默认是与电话网络时间戳同步的，所以这通常已经足够使用标准的±1偏移量了。

还有各种各样的其他情况，其中有一个明显偏离标准时间的时钟是一个问题，特别是TLS证书轮换，用户通常会发现他们的设备不适当地同步(再一次，即使是大多数计算机现在也会自动同步)将导致TOTP之外的严重问题。因此，您的重新同步化建议可能没有必要。