密码管理器和FIDO

Question

我刚刚在密码管理器中读到了一些关于FIDO支持(或缺乏FIDO支持)的文章，想看看我的理解是否正确。

我对FIDO (v1)的理解是，设备包含一个永远不会从设备中泄露出来的秘密，它所需要支持的就是基于这个秘密派生的键盘的数字签名。粗略地说，当您登录到example.com时，该设备根据某个KDF(秘密，"example.com")计算一个特定于站点的键区，然后用它签名服务器的挑战。

换句话说，FIDO令牌不需要作为秘密密钥的来源，这意味着在脱机/独立的密码管理器中使用它是没有意义的。毕竟，您希望使用没有存储在数据库中或数据库旁边的密钥对密码数据库进行加密，这就是为什么要设置主密码以从中派生密钥的原因。FIDO设备允许您证明拥有密钥，但由于它(出于实际目的)“零知识”，因此无法打开加密的数据库。

(相比之下，提供其他模式和FIDO的yubikeys与密码管理器一起使用确实是有意义的，因为它们可以保存您的密钥，并在您需要打开密码管理器时导出它。)

例如，pwsafe+yubikey存在，但pwsafe+generic FIDO不太可能很快发生。(我还没有详细检查过FIDO2标准，也许这有一种模式。)

但是你读到了像管理员密码管理器启用FIDO支持这样的东西。这是如何工作的-秘密是否以某种形式存储在他们的服务器上，只有在您成功地使用FIDO进行身份验证时才向您发布？

Answer 1

很抱歉打破了你的泡泡，其实这里只有一种Yubikey模式，对PW经理来说是完全有意义的，那就是智能卡模式，但是基本上没有真正使用它的passowrd管理器。

在线密码管理器通常使用Yubi-OTP，因为它完全兼容，只需要一个USB插槽和基本键盘驱动程序(以及一个不影响modhex的键盘布局)，但也有一些使用U2F仅仅是因为

1. 不存在任何共享秘密更安全( Yubico在云安装中使用Yubico共享机密，在自定义安装中与提供者使用共享机密)
2. 无法识别所使用的特定密钥。您知道，Yubi的前12个字符是modhex (工厂默认值)中的序列号，或者是用户在自定义它时选择的东西。另一方面，这允许后端查找正确的密钥来解密实际的OTP数据，而对于生成密钥的KDF(域、秘密)问题，您通常不会出错，但是还有一些需要考虑的问题。实际上还有第三种价值。注册时生成的随机名(这是身份验证所需的“密钥句柄”的一部分)，也是为什么即使使用单因素U2F，您仍然需要一种方法来知道您要验证的是谁(比如用户名)，以提供密钥句柄和挑战。

离线密码管理器通常与HMAC路一起使用，这实际上就是HMAC(data, secret)，根据密码管理器的详细信息，它们使用以下两种方式之一：

1. 只需使用来自HMAC(some static value,secret)的结果作为解密密钥的一部分，这确实有效，但显然是不好的，因为一次捕获会导致它的妥协。
2. Keechallenge正在做的事情:他们存储秘密，并使用它预先生成下一个结果，以便在解密过程中使用，同时存储挑战，从而导致在下一个开放过程中明显地发出挑战。

这两种方法都不是理想的，因为只看到一次解密就会破坏数据库的整个生命周期，除非不时地进行轮转(对1的挑战，2的秘密)。

考虑到yubikeys是如何在PW-DBs上工作的，我们基本上可以看到U2F如何在pw数据库中工作。

• 在线显然是数据阀，“除非你带了U2F，否则你不会得到数据库”
• 离线如蛇油
• 以类似于yubikey HMAC的脱机方式，我们保持密钥句柄打开以发出它，并且实际上使用公钥不是作为实际的公钥，而是作为生成对称加密密钥的内容。如果这听起来很疯狂，让我向你保证，这是疯狂的，但它与使用HMAC模式加密没有太大不同。

唯一真正的加密方法是Smartcard和/或PGP模式，在每次保存时都使用旋转对称密钥，因此实际上需要私钥来解密数据库，私钥仅在yubikey中。