精心设计的密码管理器不依赖身份验证来确保其安全性；相反，他们依赖加密。因此，解锁密码管理器数据库甚至不涉及单因素身份验证，更不用说多因素身份验证了。

密码管理器如何使用 Yubikey

这意味着当涉及到安全性主要基于本地或端到端的东西时，通常用于加强身份验证过程的那种东西（YubiKeys 非常擅长）扮演着本质上不同的角色加密。大致有三种方法，但每种方法的细节都是如此。

1.安全剧院

在某些情况下，明显的第二个因素是纯粹的安全剧院。可以做一些对用户来说看起来像 2FA 的事情，但任何值得担心的攻击者都可以轻松规避。多年来，我们（在我工作的 1Password 公司）一直在抵制巨大的客户压力。

让我们忽略这个选项。如果用户最终使用较弱的主密码或没有像其他方式那样保护他们的主密码，它对任何人都没有任何好处，并且有很大的潜在危害。也就是说，如果人们削弱了他们密码管理器安全性的弱点，因为他们觉得受到戏剧性 2FA 的保护，他们就会大大削弱他们的有效安全性。

2.在一些认证组件上

尽管许多密码管理器可以离线使用，而不需要对某些远程服务进行身份验证，但在设置新设备以使（至少）数据同步工作时通常需要身份验证组件。2FA 可以添加到该身份验证组件中，即使它只是用户安全性的一小部分。

顺便说一句，这就是我们使用 1Password 所做的事情。如果启用 2FA，则在设置新设备时需要它。希望通过将其限制在此范围内，我们不会让用户相信他们可以使用较弱的主密码逃脱，或者 2FA 神奇地保护他们免受获取本地加密数据的攻击者的侵害。

3.作为静态密钥的供应商

解密数据需要一个密钥，并且派生该密钥需要用户持有的秘密（通常是他们的主密码，也许还有其他东西）。这里的困难是密钥派生函数（KDF）必须是确定性的（因为它必须每次都派生相同的密钥）。

但是像 Yubikey 这样的东西的美妙之处在于它可以在不泄露秘密的情况下证明它的知识。它们被设计为以挑战-响应方式工作，其中每个挑战都是随机的，使得每次响应都是独一无二的；然而，每一个正确的回答都证明了一个秘密的知识。这就是使这些东西在身份验证上下文中真正出色的原因。但这在密钥派生期间是无用的。

因此，让 Yubikey 吐出一个静态机密就是以放弃其最重要的安全功能的模式操作设备。这是可行的（因为 Keepass 显然正在使用它，并且我们的一些用户已经操纵了类似的东西），但它确实没有提供 Yubikey 通常提供的安全保证。

尽管这不是纯粹的安全场景（有一些真正的收益），但用户仍然很可能会高估安全收益，从而削弱他们应该更强的安全部分（主密码）。

合理吗？

所以回到最初的问题。使用 (3) 中描述的 Yubikey 是否合理？只要您了解它的作用和不保护您的作用（并且这些与 Yubikey 通常保护您的作用不同），使用它并不是不合理的。）

然而，在 1Password，我们认为密码管理器鼓励 (3) 是不明智的，因为安全优势似乎不值得人们对安全属性的误解所带来的安全威胁。但是，我非常理解客户对这种事情的压力。我也明白，理性的人可能会得出不同的结论。

KeePassXC 开发人员在这里，我被定向到此线程并想添加一些评论。

来自 1Password 的 Jeffrey 的回答在技术上是准确的。YubiKey 的使用模式与其设计用途略有不同。KeePassXC 向 YubiKey 提出一个（伪）随机挑战（数据库的主种子，每次您重新加密时都会更改，即保存您的数据库）并获得唯一的响应作为回报。然后，此响应用于通过散列和将其与您的密码和（可选）您的密钥文件一起转换来增强您的解密密钥。

所以，你的 KeePassXC 数据库的 YubiKey 并不是真正意义上的第二个身份验证因素（我们正在做离线加密，毕竟不是在线身份验证），但它肯定会让你的密钥更强大。所以，这就是我认为，虽然他的技术描述是正确的，但杰弗里的结论是错误的。以这种方式使用 YubiKey 并不危险，但实际上提供了一些独特的安全优势：

1. 它为您的密码添加了 160 个伪随机位，这本身就已经比大多数用户的密码强（特别是考虑到大多数密码容易受到字典攻击）。与强密码或密码短语以及作为 KDF 的 Argon2 结合使用，它使您的数据库对任何类型的暴力攻击都具有很强的弹性。作为攻击者，您最好猜测转换后的 256 位 AES 密钥。
2. 即使您的实际密码以某种方式泄露，添加 YubiKey 也能确保您的数据库安全。这与人们使用密钥文件作为软令牌的原因相同。然而，YubiKey 比密钥文件更安全，因为它是一个独立的设备，不会被破坏，它基于隐藏的密钥执行加密计算，而密钥文件包含明文的秘密。对于密钥文件，我实际上同意 Jeffrey 的观点，即它可能会给用户一种错误的安全感，但 YubiKey 是不同的，几乎不可能被错误地使用。
3. 它为您提供了其他静态对称加密方案，您可以称之为“伪前向（或后向？）保密”。即使攻击者同时掌握了您的密码和特定的 YubiKey 响应，他们也无法解密您数据库的任何先前版本甚至未来版本。当然，在这种情况下，无论如何您都必须更改所有暴露的密码，但它增加了额外的保护，防止在攻击者侵入您的数据库和您注意到暴露之间添加的任何新密码受到损害，并且它还保留以前的密码在暴露的数据库中不再安全（可能没有那么有价值，但在某些情况下实际上可能会有所帮助）。
4. YubiKey 响应不会出现在屏幕上，并且不使用传统的键盘界面。这并不是真正的安全属性，但如果您的系统受到不拦截所有 USB 输入的通用键盘记录器的破坏，它有时会有所帮助。当然，更专业的键盘记录器可以完全拦截 YubiKey 响应，因此我不相信这是一种防御措施，但在某些情况下它可能会有所帮助。但是，一般来说，如果您的系统上有恶意软件，您的数据将会丢失。在这种情况下，您唯一可以尝试的就是减轻损害，但总的来说，受感染的系统不再是您的系统，所以不要指望有任何有效的对策来对付键盘记录器，而不是一开始就没有。

我更新了我们的常见问题解答，使其在术语上更加精确，并包含了一些额外的细节。

这种情况下的 Yubikey 不是 MFA，因为除了 CR 输出之外，质询-响应模式不需要使用密码。这就是为什么 yubikey 经常会在文本字段中输入乱码，而用户不小心敲到了令牌的侧面。在这种模式下运行，Yubikey 只不过是一个用于输出密码的自动键盘。

现在，有趣的是，除了保存数据库时，数据库系统 KeePassXC 实际上并没有更新他们对 Yubikey 的挑战。因此，如果您的数据库只是不时读取而没有更改，那么预期的挑战不会改变。这意味着 Yubikey 将返回相同的响应值，因为身份验证系统不要求新的响应。在我对应用程序的有限理解中，这是 KeePassXC 可以改变的限制，但由于某种原因没有改变。

Yubico 关于挑战-响应模式的信息：

https://www.yubico.com/products/services-software/personalization-tools/challenge-response/

这意味着...如果您承诺每次运行时都保存 KeePassXC 数据库，那么即使使用键盘记录器，您仍然可以信任 Yubikey 的使用。在这种情况下，每次解密时，数据库都会期待一个新的响应，而之前的响应将不起作用。但是，这需要您作为用户的高度努力，并且在很长一段时间内可能并不理想。

是的，这是合理的（在一些额外的假设下）。

虽然对本地恶意软件几乎无能为力（如上所述），但还有其他攻击媒介需要注意。

在您使用笔记本电脑的任何地方，请注意您的解锁密码会泄露给您周围的摄像头。

有了物理硬件密钥，就多了一层安全性。由于笔记本电脑和硬件密钥通常会一起移动并被扣押，因此只有在硬件密钥本身受到保护（任何人都无法插入和使用）的情况下，这才有意义。