将KeePassXC与YubiKey结合使用是否合理？

Question

目前，我使用的KeePassXC具有一个相对较强的主密码。为了进一步提高安全性，我考虑购买一个YubiKey来进行二因素认证。

KeePassXC支持所谓的"HMAC-SHA1挑战响应模式“。

在KeePassXC常见问题中，他们说：

KeePassXC是否支持YubiKeys的双因素身份验证(2FA)？是也不是。KeePassXC支持保护数据库的YubiKeys，但严格地说，它不是双因素身份验证。KeePassXC生成一个挑战，并使用YubiKey对此挑战的响应来增强数据库的加密密钥。因此，在某种意义上，它使您的密码更强，但从技术上讲，它并不是一个单独的第二个因素，因为预期的响应并不是每次您试图解密数据库时都会改变。但是，每次保存数据库时都会发生更改。

假设攻击者能够访问我的KeePassXC数据库，甚至在我的系统上安装了一个密钥记录器，那么在这种情况下，附加的YubiKey是无用的，我在这里吗？

那么，如果您已经使用了强大的主密码，那么为KeePassXC使用硬件安全密钥是否合理呢？

Answer 1

这里的KeePassXC开发人员，我被介绍到这个线程，并想添加一些注释。

杰弗里的答案在技术上是准确的。YubiKey是在一种与其设计目的略有不同的模式下使用的。KeePassXC向YubiKey提出(伪)随机挑战(数据库的主种子，每次重新加密(即保存数据库)时都会改变)，并得到唯一的响应。然后，通过散列并将解密密钥与密码和(可选)密钥文件一起转换，此响应将用于增强解密密钥。

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

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

我更新了我们的常见问题，使其更加精确的术语，并包括一些额外的细节，以及。

Answer 2

设计良好的密码管理器不依赖于身份验证来获得安全性，而是依赖于加密。因此，解锁密码管理器数据库甚至不涉及单因素身份验证，更不用说多因素身份验证。

密码管理器如何使用Yubikey

这意味着，通常用来加强身份验证过程( YubiKeys非常擅长)的东西在安全性方面发挥着本质上不同的作用，主要是基于本地加密或端到端加密。大约有三种方法，但每一件事的细节。

1.安全剧场

在某些情况下，明显的第二个因素是纯粹的安全剧场。在用户看来，可以做一些类似2FA的事情，但任何攻击者都可以轻松地回避，值得担心。多年来，我们(在1 1Password，我工作的地方)一直抵制着强烈的客户压力。

让我们忽略这个选项。如果用户最终使用的是较弱的主密码，或者没有保护他们的主密码，那么它就有很大的危害潜力。也就是说，如果人们削弱了密码管理器安全中已经存在的弱点，因为他们觉得自己受到了戏剧2FA的保护，那么他们的有效安全性就会大大削弱。

2.在某些身份验证组件

上

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

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

3.作为静态密钥

的供应商

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

但是，类似于尤比基的东西的美妙之处在于，它可以证明一个秘密的知识，而不泄露它。它们被设计成以一种挑战响应的方式工作，其中每个挑战都是随机的，使得每次的回答都是独一无二的；然而，每一个正确的反应都证明了对一个秘密的了解。这使得这些东西在身份验证上下文中非常好。但在密钥推导过程中，这是无用的。

因此，让Yubikey泄露一个静态的秘密是在一种放弃其最重要的安全功能的模式下运行设备。这是可行的(因为Keepass显然在使用它，我们的一些用户也安装了类似的工具)，但它实际上并没有提供Yubikey通常所提供的安全保证。

虽然这并不是纯粹的安全领域(有一些真正的收益)，但用户仍然有明显的可能会高估安全增益，从而削弱他们应该更强的安全性部分(主密码)。

是合理的吗？

回到原来的问题。如(3)所述，使用Yubikey是合理的吗？只要您了解它所做的和不保护您的事情，使用它并不是不合理的(而且这些与Yubikey通常保护您不受的东西不同)。

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

Answer 3

本例中的Yubikey不是MFA，因为问题响应模式除了CR输出之外不需要使用密码。这就是为什么yubikey经常在文本字段中键入胡言乱语，用户会意外地敲掉他们的令牌。在这种模式下运行，Yubikey不过是一个自动键盘，用于输出您的密码。

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

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

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

这意味着在每次运行is...if数据库时，您都致力于保存KeePassXC数据库的实践，那么即使使用密钥记录器，也仍然可以信任Yubikey的使用。数据库每次在此场景中解密时都会期望得到一个新的响应，而之前的响应将无法工作。然而，这将需要您作为用户的高度勤奋，在很长一段时间内可能不可取。