我今天拿到了 YubiKey 4，并首先尝试将 KeePass 与 OATH-HOTP（OtpKeyProv 插件）一起使用。我的配置是 3 个 OTP，预读计数 = 0。它工作得不是很好，因为有时当我按下按钮太快时 OtpKeyProv 插件无法识别我的输入。所以我改成 6 个 OTP，前瞻计数 = 12。但是这样就不再“那么舒服”了，因为我需要按下按钮 6 次并且必须在按下之间等待几秒钟以确保插件能够识别输入。
所以我尝试了使用 KeeChallenge 插件的挑战-响应方法。它完美无瑕。有什么反对使用带有 KeeChallenge 插件的挑战-响应方法或者它可以安全使用吗？我知道 OtpKeyProv 插件更安全，但这有那么大的不同吗？
取决于插件如何在内部执行它，这可能是增加安全性的一种非常有趣的方式。
本质上，这个东西滥用了 HOTP，通过计算下一个所需的 OTP 并将它们与主通道一起形成以加密数据库。
但是当然，当您激活前瞻功能时（您确实应该，尤其是在 nano 上）它会生成更多的键序列，以防您意外增加了计数器。
它背后的想法并不坏，尽管显然keepass需要将种子（共享秘密）存储在数据库中以允许重新加密它。
keechallenge 插件在相同的前提下工作：用某种挑战（HOTP 中的计数器）散列共享秘密，但从某些角度来看，这个插件实际上更安全。
1) 它提供 HMAC-SHA1 的 160 位输出，而不是“仅” log2(10^(6*x)) 位（x 是您选择的连续 OTP 的数量，8 个连续的 OTP 会达到 159 和半位长度）
简单地说，对于相同的安全级别，您需要更少的点击，虽然 OTP 插件可能被配置为使用大量 OTP 以获得更高的安全性，但经过修改，Challenge-Response 插件也可以运行多个挑战，抛出数字钻头通过屋顶，再次只需八分之一所需的抽头（不用担心误抽头和没有得到正确的顺序）。
2）由于挑战是从数据库中提供的，我们不需要担心意外触摸键或前瞻，这意味着我们不需要通过允许多个第二因素解决方案进入来降低安全性。
简单地说，数字 2 意味着 Yubi 只有 Secret，而 DB 具有可以称为挑战的“状态”，而在 TOTP 中，Yubi 具有解密 DB 所需的状态和秘密，并且状态每次都会更改您触摸键，这意味着您需要考虑多个状态。
尽管显然共享秘密仍然需要以一种或另一种方式存储在数据库中（除非您根本不改变挑战，但这是鲁莽的）。
您应该知道，使用 KeePass 实现 2factor 的任何机制都不会从根本上增加任何真正的安全性。任何获得您的数据库的攻击者都不会安装 OTPKeyProv 插件，并且不需要使用第二个因素。
OTP 2-factor 提供身份验证，而不是加密，并且仅适用于攻击者在身份验证之前无法直接访问密码库的情况，例如使用 LastPass 等在线服务。使用 KeepPass，攻击者必须在身份验证期间访问数据库，因此可以简单地下载数据库并忽略身份验证部分。
更简单地说：使用 OtpKeyProv 不会为您的主密钥添加任何安全性，并且主要是安全性的。
编辑：我在某些方面得到了纠正——根据插件作者的回复，该插件旨在为主密码添加一个额外的密钥并使用 HOTP 保护它。具体如何做到这一点尚不清楚，但听起来似乎是合理的。但是，需要注意的是，这并不是真正的 2-factor，而更像是 factor-and-a-half；主要因素（加密密钥）正在通过一个本身受到弱保护的较弱密钥来加强。所以它是额外的安全性，但不如身份验证系统中真正的 2 因素提供那么多。