OTP 和质询/响应方案之间的一个重要区别是第一个可以被欺骗，而第二个不能。假设有人为 KeePass 设置了一个网络钓鱼 UI，并且您在其中输入了密码，却没有意识到它不是合法的。攻击者意识到密码不够，您启用了 MFA。到现在为止还挺好。

但是，如果您使用 OTP，攻击者需要做的就是显示通常的 OTP 输入框。你点击你的 Yubikey，它会将 OTP 发送给攻击者，攻击者将其转发给 KeePass，然后他们就可以访问你的 KeePass 保险库了。如果您改为使用挑战/响应，则 Yubikey 的响应基于来自应用程序的挑战。攻击者不知道发送 KeePass 的正确挑战，因此他们无法欺骗它。

请注意，这种区别对于像 KeePass 这样的胖客户端本地应用程序可能并不重要，但对于任何进行远程身份验证的东西来说绝对重要。例如，如果您正在登录 Gmail 等网络应用程序，则网络钓鱼页面可以欺骗登录 UI 和 OTP UI。但是，网络钓鱼页面不能欺骗挑战/响应流程，因为这是基于访问的实际站点，即使您看起来相同，您的浏览器（以及 Yubikey）也会发送不同的挑战。

事实上，像这样的质询-响应系统是我所知道的唯一一种可以提供非常强大的安全性来抵御网络钓鱼攻击的方法。涉及真正第二因素的所有其他因素 - OTP、SMS，甚至推送通知 - 都可能被欺骗，您将像往常一样接受身份验证检查，因为据您所知，您正在像往常一样登录。

在我看来，“使用 OTP 的 Keepass 2”不能“安全”。为什么？

OTP 不能用于加密数据

Keepass 加密数据，加密数据的问题在于，您加密数据是因为您想保护它免受离线攻击。因此，可以访问加密形式的数据，并且您希望避免攻击者可以以明文形式读取它。但如果攻击者拥有加密数据，他可以进行离线暴力攻击。而 HOTP，创建 6 位或 8 位数字并不能真正增加保护免受离线攻击的影响。它可以简单地为您的密码添加 6 位数字！这对于在线身份验证来说很好，当帐户在一定次数的失败尝试后被阻止时。但是使用 OTP 派生加密密钥是没有意义的。

OTP 的问题是，它很短，因为它可以很容易地用于身份验证，因为每个人都可以在任何地方输入它。这很酷 - 但仅适用于预期的用例！

我不建议将 OTP 用于 keepass！

使用挑战响应

使用质询响应没有此限制。不要误会我的意思，OTP 有它存在的权利！挑战响应的问题是：您需要驱动程序！因此，在某些身份验证场景中，OTP 比质询响应更好（不是更安全！）。

但是回到keepass 2和驱动程序。好吧，有了keepass，这没问题，因为无论如何您显然都拥有它们。Yubikey 的挑战响应模式使用对称密钥。您可以向 yubikey 发送挑战，它将根据挑战和密钥创建一个 hmac，并以 256 位返回值进行响应。现在，您需要相同的挑战和相同的密钥来始终创建相同的返回值。显然返回值被用作加密密钥（实际上秘密密钥被用作加密密钥，但它与响应值加密存储）但归根结底，你需要秘密密钥解密数据。由于我们在这里讨论的是不同的密钥长度（而不是 6 位数字），因此密钥与 AES 加密密钥本身一样难以暴力破解。在这里阅读：http : //richardbenjaminrush.com/keechallenge/#using

我建议使用挑战/响应！

免责声明：当然，我没有进行代码审查或任何深入分析。这简直就是从官方对两种机制的基本概念的评价！