“每个人”都知道在数据库中存储密码时应该安全地完成，例如通过使用盐和适当的散列算法。
大多数 OTP（一次性密码）解决方案都基于长秘密随机种子值。不知何故，这也需要存储在验证服务器上，以便能够验证提交的 OTP 值。
在某种程度上，这些种子与用户提供的密码具有相同的作用，并且需要同样安全地存储。加盐和散列在这里不起作用，因为这会破坏 OTP 算法。
大多数小型 OTP 令牌通过或多或少的防篡改在物理上得到保护，但这不适用于服务器。
种子如何以适当的方式储存？
如果有一种无需散列存储种子的解决方案，为什么不将相同的方法应用于常规密码呢？
您可以使用从用户密码派生的对称密钥来加密 OTP 种子。但是，这需要用户在输入 OTP 之前输入密码，否则服务器无法解密 OTP 种子。
或者，您可以拥有一个高度安全的服务器，该服务器通过加密的 OTP 种子并返回当前有效的 OTP。种子的对称密钥存储在此服务器上。HSM 也可以在这里为您提供帮助。
粗略地说，您能做的最好的事情就是强化服务器，使其尽可能地抵抗妥协。
理想情况下，您会将种子存储在硬件安全模块（HSM；又名加密协处理器）中。您要确保种子永远不会离开 HSM，即在 HSM 中进行所有加密计算。这提供了更好的保护，尽管它确实更昂贵。
但是，正如您正确指出的那样，您不能以散列形式存储种子。种子必须以明文形式存储，因此如果该服务器 遭到入侵，您就有 大 麻烦了。这意味着尽可能地保护该服务器是绝对重要的。
OTP 种子与密码不同。人们倾向于在多个站点上使用相同的密码；OTP 种子不会发生这种情况。散列密码部分用于保护用户的密码，因此如果站点 X 的数据库被破坏，那么 X 在其他站点上的用户帐户不会受到损害。这种威胁根本不适用于 OTP 种子。
此外，使用密码，您可以散列密码。如果可以，你也可以，因为它确实有助于减轻一些风险。（而且密码被广泛使用，并且被非安全专家的开发人员使用，以至于许多使用密码的网站在某些时候都会遇到安全漏洞。）由于你不能散列 OTP 种子，所以这缓解措施根本不适用于 OTP 种子——因此您必须使用其他方法来保护您的 OTP 种子。幸运的是，只有非常具有安全意识的站点才应该存储自己的 OTP 种子，因此如果一个人持乐观态度，可能会希望他们能够更好地应用其他防御措施。
无论如何，由于 OTP 种子与密码具有不同的特征，因此您不应假设密码的每个缓解措施都必然会转移到 OTP 种子。
假设您的 TOTP 时间范围为“T”。即您的 OTP 在 T 时间后过期。可以做的是（针对所有用户一一）如果用户在当前时间之前没有请求 OTP T 时间，您可以更改种子。由于用户在我们的时间窗口内没有请求 otp，我们可以确定没有 OTP 尚未被我们的服务器验证。所以，万一攻击者得到它的种子，种子就会改变。