我正在构建一个基于 TOTP/HOTP 的双因素身份验证系统。 为了验证 otp，服务器和 otp 设备都必须知道共享 key 。
由于 HOTP 密码与用户密码非常相似，我认为应该应用类似的最佳实践。特别是强烈建议永远不要存储未加密的密码，只保留密码的加盐哈希值。
RFC 和 HOTP/TOTP 的 python 实现似乎都没有涵盖这方面。
有没有一种方法可以使用 OTP 共享 key 的单向加密，或者这是一个愚蠢的想法？
最佳答案
Is there a way to use one-way encryption of the OTP shared secret...?
不是真的。您可以使用可逆加密机制，但这可能没有多大意义。
你只能散列一个 HMAC如果客户端通过网络发送完整的未散列的 HMAC key 进行身份验证，则服务器上的 key ，这通常是基于密码的身份验证的工作方式，但这很容易受到重放攻击，这正是 HOTP/TOTP 旨在避免的。
why do we apply 1-way function to a password before storing it (salt+hash)...?
这实际上是个好问题。
我认为这是因为早期版本的 Unix 操作系统将其所有密码信息存储在一个“世界可读”的 /etc/passwd 文件中，因此显然必须对其进行混淆处理在某种程度上，salt+hash 恰好是他们选择的方法。
如今，人们通常不会如此自由地提供他们的密码文件，因此可以说根本不需要对它们进行哈希处理。
然而，还有一个混淆它们的原因，那就是密码通常是由人类选择的，因此为了方便起见，它们通常会为多个系统选择相同的密码。我怀疑 HMAC key 也是如此，它们(希望)是使用更强大的加密机制选择的。
因此，如今散列密码的主要原因与其说是为了提高系统的安全性，不如说是为了降低危及用户在其他系统上的安全的风险，如果您的系统已被破坏。
如果攻击者可以从您的系统中读取明文密码，这对他们来说可能没有多大用处，因为无论如何他们也可能读取系统上的所有其他内容。
但是，如果在另一个系统上也使用了相同的密码，那么您可能已经为攻击者提供了破坏该系统的方法。
如果可以相信人类不会对多个系统使用相同的密码，那么可能根本不需要对它们进行哈希处理，但我认为假设这种情况有可能发生有点乐观。 :-)
关于python - 是否可以在服务器上加盐和/或散列 HOTP/TOTP secret ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15962195/