概括。不，该代码看起来不安全。它没有足够的熵来让对手无法预测。我不会重复使用该代码。

正确的方法。要生成随机码，我建议您从/dev/urandom. 这是一个一次性代码，它需要是随机的、不可猜测的和强大的密码学。这正是/dev/urandom提供的。经过深思熟虑，操作系统制造商已经制定出如何安全地做到这一点，并且该方法已经过安全专家的审查。我建议你简单地重新使用他们现有的工作。

的分析second_factor_regenerate_token。 我不知道我是否正确理解了代码，但看起来它没有足够的熵。它散列用户的用户名、用户密码、HTTP 标头和当前时间。这还不够熵。

请记住，第二个因素的目的是防止未经授权的个人以某种方式知道用户的用户名和密码，从而访问系统。（如果未经授权的个人不知道用户的用户名和密码，那么我们不需要第二个因素；第一个因素已经阻止了他们。）所以我们的分析应该从攻击者知道用户的用户名和密码的假设开始.

一旦我们做出这样的假设，剩下的唯一熵就来自当前时间和 HTTP 标头。时间绝对没有足够的熵：它会被攻击者知道或几乎知道（由于时间同步不完善，可能会延迟几秒钟，但攻击者可以尝试所有可能性）。我不知道 HTTP 标头中会有多少熵，但这听起来不像是安全的坚实基础。

因此，根据我对 的解释second_factor_regenerate_token，假设我正确理解了代码的工作原理，我认为它并不代表良好的安全工程。我不会重复使用该代码。

查看HOTP背后的动机，它是为此类应用程序设计的。

您想要的一些功能是：

• 根据需要生成一次性密码（在这种情况下，在用户完成初级身份验证后）

• 可行发送，显示在用户手机上，输入

• 可在多次请求新密码、错误排序或跳过发送等情况下进行验证

• 足够高的熵（不是基于已知信息，例如第一因素用户名或密码，如果早先的密码已知，则不可猜测）

使用 HOTP，您可以为每个用户存储一个密钥和计数器，两者都不会发送。要生成一次性密码，您需要对密钥和计数器进行哈希处理，发送哈希值，然后递增计数器。要验证密码，您需要对密钥和一系列计数器进行散列并比较它们。

您可以按照这些思路自行开发，但 HOTP 是一个标准。您可以为您的系统找到经过审核的实现，并可以找到社区帮助来决定它是否适合您。