问通过OTP添加双因素身份验证真的会使KeePass更加安全吗？

EN

不是的。安全性仍然是相同的+额外的认知开销。

据推测，该插件使用誓约HOTP，其中KeePass文件或主密钥在每次访问后用下一次密码重新加密。

但是，要在设备上生成下一个密码，插件要么需要存储在设备上的秘密，要么需要KeePass文件的正常密码。

来自一次性密码的安全性来自知道相同密钥和计数器HOTP(Key,Counter)的双方，而攻击者不知道密钥。如果攻击者访问了存储KeePass安装和文件的设备，则安全性将自动恢复到正常密码的安全性。如果KeePass文件仍然可以与其他KeePass程序互操作，那么以这种方式使用一次性密码将一无所获。

一次密码用于服务器身份验证很好，因为客户端和服务器端点都被认为是安全的，攻击者需要“您拥有的东西”以及“您知道的东西”。如果攻击者拥有您的计算机，那么他们现在拥有“您拥有的东西”。

从读取源代码看，这个秘密似乎存储在Yubikey上，并在otp.xml文件中使用不同的密钥进行多次加密存储。加密密钥来自从OTP i..i+m开始的下一个n个OTP(从秘密导出)，其中I是当前计数器，m是前瞻性值。当用户输入他们的OTP值时，插件将从这些值创建一个密钥，并尝试使用该密钥解密一个加密的秘密副本。如果成功，该秘密将用于派生下一个n+m OTP并生成用于下一次加密该秘密的m个密钥，然后再解锁数据库。这意味着，如果没有秘密的一些副本，保护就不能被绕过，而秘密不是存储在数据库旁边的纯文本。

虽然显然是安全的，但我不喜欢这个插件，因为计数器可能不同步。一定要把秘密的副本写在安全的地方。

KeePass有一个主密钥，通常是用密码加密的.如果该密钥是用OTP生成的内容和密码加密的，则需要两种机制来解密加密数据存储的主密钥。尽管如此，我不知道他们如何实现一个安全的OTP设置，因为OTP通常是一种身份验证方法，而不是密钥存储(我不知道您如何让OTP解锁密钥)。

还怀疑它们能够有效地防止重播，因为数据库在大多数攻击场景中都是由攻击者控制的，只是不一定以您预期的方式。他们可能有办法解决这个问题，但我想不出一个。