在服务器上是否可以对HOTP/TOTP密钥进行盐化和哈希处理？

Question

我正在构建一个基于TOTP/HOTP的双因素认证系统。 为了验证otp，服务器和otp设备都必须知道共享秘密。在

因为hotpsecret与用户的密码非常相似，所以我认为应该应用类似的最佳实践。特别是，强烈建议不要存储未加密的密码，只保留密码的咸散列值。在

rfc和HOTP/TOTP的python实现似乎都没有涵盖这一方面。在

有没有一种方法可以使用OTP共享机密的单向加密，或者这是一个愚蠢的想法？在

Answer 1

Is there a way to use one-way encryption of the OTP shared secret...?

不是真的。你可以使用一个可逆的加密机制，但可能没有什么意义。在

如果客户端通过在网络上发送完整的未经修改的HMAC密钥进行身份验证，则只能在服务器上散列一个HMAC密钥，这通常是基于密码的身份验证的工作方式，但这很容易受到重播攻击，这正是HOTP/TOTP旨在避免的。在

why do we apply 1-way function to a password before storing it (salt+hash)...?

这实际上是个好问题。在

我认为这源于这样一个事实：早期版本的Unix操作系统将其所有的密码信息存储在一个“全世界可读”的/etc/passwd文件中，因此它们显然必须以某种方式加以混淆，salt+hash恰好是他们选择的方法。在

现在，人们通常不会让他们的密码文件如此自由地可用，所以可以说根本没有必要对它们进行哈希处理。在

然而，还有另一个使它们混淆的原因，那就是密码通常是由人类选择的，因此，为了方便起见，他们通常会为多个系统选择相同的密码。我怀疑HMAC密钥也是如此，它们是（希望）使用更加密的机制选择的。在

因此，现在散列密码的主要原因，与其说是为了提高系统的安全性，不如说是为了降低在其他系统上危及用户安全的风险，如果您的系统遭到了破坏。在

如果攻击者可以从您的系统中读取明文密码，这可能对他们没有多大用处，因为他们可能也可以读取系统上的所有其他内容。在

但是，如果在另一个系统上也使用了同一个密码，那么就有可能给攻击者提供了破坏该系统的手段。在

如果可以相信人类不会在多个系统中使用同一个密码，那么可能根本就没有必要对它们进行哈希处理，但我认为，假设这种情况发生的可能性有点乐观。：-）

Answer 2

定义：HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF-其中K是密钥，C是计数器。由于HMAC是单向散列（而不是双向加密），因此如果黑客拥有HOTP字符串，则黑客无法获得K和{}。在

K&；C需要保护，因为丢失会危及整个OTP系统。话虽如此，如果K是在字典中找到的，并且我们知道C（例如：当前时间），我们就可以生成HOTP/TOTP的整个字典并计算出K。在

对HOTP/TOTP应用单向加密（即：双重加密）在数学上会增加解码难度，尽管它不能防止其他形式的攻击（例如：击键记录）或对HOTP/TOTP的字典列表应用相同的加密。在

人类的天性是，重复使用同一套容易记住的密码，因此需要在数字设备上或通过互联网传输时隐藏此密码。在

安全过程或协议的实现也是至关重要的，这就像选择了一个好的密码K，但却把它放在办公桌上，或者持有{}（对于HMAC）的服务器不在由几层防火墙保护的私有网络内。在