身份验证方法通常可以分为三个领域之一：用户知道的东西、用户拥有的东西和用户所拥有的东西。

密码是用户知道的东西。用户将它记住在他的脑海中，并且可以在需要时从内存中“检索”它。

密钥文件充当用户拥有的东西。理想情况下，此密钥文件需要存储在安全位置。

就个人而言，我到处都有我的密码数据库的副本。我的台式机有一个副本，我的笔记本电脑有一个副本，我的手机有一个副本，我的平板电脑有一个副本。我将密码数据库存储在 Dropbox 上，这样我就可以在各种设备之间保持同步。

但是，我不会将密钥文件与密码数据库一起存储。我的手机和平板电脑有它的副本，因为我无法将 USB 驱动器插入这些设备，但我的台式机和笔记本电脑却没有。我将密钥文件存储在随身携带的 USB 驱动器上。这使得攻击者获取我的密钥文件变得更加困难。

除了主密码之外，使用密钥文件很有帮助，因为它增加了成功破坏密码数据库的难度。

他们的密钥文件包含用于加密数据库的密钥。它通常还受密码保护。如果您没有密钥文件，则不可能从密文中获取密钥，获得等价的明文。因此，如果攻击者获取您的数据库，他仍然需要获取您的密钥文件，即您拥有的. 如果密钥文件另外用密码加密（你应该这样做），那么他还需要你知道的东西。所以这是认证的两个因素。

如果您将密钥文件存储在数据库中，攻击者将“只”需要对密钥文件进行暴力破解或字典攻击（这比攻击整个数据库要小得多，花费的时间也少得多）。但是，如果您有一个复杂的密码，这应该仍然需要几乎永远（取决于您的密码随机性/熵）。

但是添加另一个因素确实会增加额外的安全性，因为攻击者仍然需要从您那里获得两件东西，而不是一件。

这有点像将钥匙存储在钥匙串上。但你不会把钥匙放在锁着的门旁边，对吧？嗯，这是相似的。

密钥文件还有第二个优势，与模拟双因素身份验证 (2FA) 不同。尽管您对问题的修订表明两个因素的答案是您在答案中寻找的。

不直接从主密码派生加密密钥的另一个原因是允许随机创建密钥，而不是直接从主密码派生。如果我们使用 CSPRNG 创建密钥，然后使用密钥加密密钥 (KEK) 加密该密钥，那么我们可以确保主密钥具有其比特大小的全部强度。那是一个 128 位密钥实际上是 128 位强的，即使个人选择了一个糟糕的主密码。

尽管对称密钥（如密码管理器中使用的）不需要这样做，但在查看公钥系统时它绝对是至关重要的。在这些情况下，私钥不能只是任何东西，因此不能真正成为密码和一些盐的功能。所以这就是为什么对于 PGP 或 SSH 之类的东西，密钥是由软件生成的，然后使用从密码派生的 KEK 进行加密。

当然，从主密码推导 KEK 仍然需要使用 PBKDF2 或 scrypt 等密钥推导函数“拉伸”。

两个因素，但不是身份验证

注意：我说“模拟两因素身份验证”的原因是因为在这些情况下实际上没有身份验证。取而代之的是解密。出于许多目的，区别并不重要，但在某些关键情况下，将身份验证密码（或令牌）与加密令牌区分开来是巨大的。

对于像 KeePass 这样不基于身份验证的东西（您没有向某些服务证明您是谁，然后在成功后向您发布内容），您需要将密钥文件获取到您需要使用的每台计算机或设备你的数据。因此，如果您还希望解密手机上的数据，则将其放在 USB 上可能行不通。使用 KeePass 可能有很多方法可以做到这一点，但鉴于我对架构的（可能有缺陷的）理解，它会带来一些需要克服的困难。

除了充当“您拥有的东西”之外，使用密钥文件的选项允许在其他两个因素（“您知道的东西”和“您的身份”）方面具有更大的灵活性，而无需在应用程序中明确实现此类行为。

示例 1： “你知道的事情”可以通过自定义或更强大的 密钥派生函数运行，而不是 KeePass（特别是 v1.x 兼容）可以支持；然后作为密钥文件加载。

示例 2： “Something you are”可以通过生物识别扫描仪运行，该扫描仪写出生物签名，然后通过陷门函数和/或密钥派生函数运行，以加载到对生物识别没有原生感知的 KeePass，尤其是在没有“TWAIN”等效生物识别标准的操作系统上。

示例 3： 更一般意义上的“你是某物”证明你是一个人* 通过从人类键入的 CAPTCHA 图像（或一个或 另一个可能的继任者）中重新生成密钥文件（或其中一个阶段），同时公开存储密钥库。

基本上，该keyfile选项可以作为您可以想象的任何熵源的通用包罗万象 - 在底层密钥库加密方案的限制内（KeePass 为256 位）。

_{* 或 HAL 9000。}