我正在构建一个基于 TOTP/HOTP 的双因素身份验证系统。为了验证 otp，服务器和 otp 设备都必须知道共享密钥。
由于 HOTP 密码与用户密码非常相似，因此我认为应该应用类似的最佳实践。具体来说，强烈建议不要存储未加密的密码，只保留密码的加盐哈希。
RFC 和 HOTP/TOTP 的 python 实现似乎都没有涵盖这方面。
有没有办法使用 OTP 共享密钥的单向加密，或者这是一个愚蠢的想法？
问问题
2979 次
2 回答
9
有没有办法使用 OTP 共享密钥的单向加密......？
并不真地。您可以使用可逆加密机制，但可能没有多大意义。
如果客户端通过网络发送完整的未散列 HMAC 密钥进行身份验证，您只能在服务器上散列HMAC密钥，这通常是基于密码的身份验证的工作方式，但这很容易受到重放攻击，这正是 HOTP/ TOTP 旨在避免。
为什么我们在存储密码之前将单向函数应用于密码（盐+哈希）......？
这实际上是一个好问题。
我认为这源于早期版本的 Unix 操作系统将其所有密码信息存储在“世界可读”/etc/passwd文件中，因此显然必须以某种方式对其进行混淆，而 salt+hash 恰好是方法他们选择了。
如今，人们通常不会免费提供他们的密码文件，因此可以说根本不需要散列它们。
然而，混淆它们还有另一个原因，那就是密码通常是由人类选择的，因此，为了方便起见，他们通常会为多个系统选择相同的密码。我怀疑 HMAC 密钥也是如此，它们（希望）是使用加密更强的机制选择的。
因此，如今散列密码的主要原因与其说是为了提高系统的安全性，不如说是为了降低在您的系统受到威胁时损害您的用户在其他系统上的安全性的风险。
如果攻击者可以从您的系统中读取明文密码，那么这对他们来说可能没有多大用处，因为他们可能也可以读取系统上的所有其他内容。
但是，如果在另一个系统上也使用了相同的密码，那么您可能已经为攻击者提供了破坏该系统的手段。
如果可以信任人类不会对多个系统使用相同的密码，那么可能根本不需要对它们进行哈希处理，但我认为假设这可能会发生有点乐观。:-)
于 2013-04-15T16:45:16.120 回答
0
定义：HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF- 其中K是密钥，C是计数器。它的设计是为了让黑客无法获得K，C如果他们有 HOTP 字符串，因为 HMAC 是单向哈希（不是双向加密）。
K&C需要受到保护，因为丢失会危及整个 OTP 系统。话虽如此，如果K在字典中找到并且我们知道C（例如：当前时间），我们可以生成 HOTP/TOTP 的整个字典并找出K.
将一种方式加密应用于 HOTP/TOTP（即：双重加密）在数学上会使其更难解码，尽管它不能防止其他形式的攻击（例如：击键记录）或将相同的加密应用于 HOTP/ 的字典列表托普。
为所有内容重复使用同一组易于记住的密码是人类的天性，因此需要在数字设备上或通过互联网传输时隐藏此密码。
安全程序或协议的实施也很重要，这就像选择一个好的密码K但把它放在桌子上供每个人使用，或者服务器持有K（对于 HMAC）不在受几层防火墙保护的专用网络内。
于 2013-04-19T17:20:32.250 回答