我得到的答案很好，但我想提供更深入的内容，具体说明系统存在的原因，这应该更多地解释它的好处。

免责声明：虽然我现在为 Google 工作，但在撰写此答案时我对这个项目一无所知。这里报道的一切都是从公共来源收集的。这篇文章是我自己的意见和观察和评论，并不代表谷歌的意见、观点或意图。

尽管值得指出的是，我已经使用它并对其进行了相当长的一段时间的修改，并且作为一个处理过很多社会工程和帐户接管的人，我对这里所取得的成就印象特别深刻。

为什么需要新的东西

想一想：谷歌很久以前就部署了双因素身份验证。这是一家非常关心安全的公司，他们的一直是一流的。虽然他们已经在使用最好的技术，但 U2F 提供的高于传统 2 因素的额外安全性非常重要，值得公司花时间和金钱来设计、开发、部署和支持他们没有的替代系统' t连自己都卖。是的，他们走这条路是一个非常具有社会意识的举动，但这不仅仅是关于社区。谷歌这样做也是因为他们自己需要 U2F 单独提供的安全性。很多人相信谷歌提供他们最宝贵的信息，. 谷歌需要能够提供这种信任的安全性。

它归结为网络钓鱼。网络钓鱼是一件大事。这是非常常见和超级有效的。对于针对强化目标的攻击，网络钓鱼和类似攻击确实是攻击者的最佳选择，而且他们知道这一点。更重要的是：

我们的网络钓鱼保护是可笑的。我们有两因素身份验证，但实施提供的防御很少。SecurID、Google Authenticator、电子邮件、电话和 SMS 循环等常见系统 - 所有这些系统都没有提供任何针对使用时间网络钓鱼攻击的保护。一次性密码仍然是密码，它可以泄露给攻击者。

这不仅仅是理论上的。我们已经看到这些攻击实际进行了。事实上，攻击者确实会捕获发送到网络钓鱼站点的第二因素响应，并立即在真实登录页面上播放它们。这实际上正在发生。

所以说你是谷歌。您已经部署了可用的最佳保护，但您会发现它们还不够。你做什么工作？没有其他人为您解决这个问题；你必须弄清楚。

解决方案很简单；收养是真正的问题

创建一个无法被网络钓鱼的次要解决方案非常简单。您所要做的就是让浏览器参与进来。在 U2F 的情况下，设备为每个站点创建一个公钥/私钥对，并将站点的身份刻录到站点应该用来请求身份验证的“密钥句柄”中。然后，每次尝试任何身份验证之前，浏览器都会验证该站点身份。站点身份甚至可以绑定到特定的 TLS 公钥。而且由于它是一个挑战-响应协议，因此也无法进行重放。如果服务器在数据库泄露中意外泄露了您的“密钥句柄”，它仍然不会影响您的安全或泄露您的身份。使用此设备可有效消除网络钓鱼的可能性，这对于一个对安全敏感的组织来说是一件大事。

加密货币及其应用都不是新的。两者都很好理解和信任。技术从来都不是难点，难点是采用。但谷歌是少数能够克服通常阻碍此类解决方案的障碍的参与者之一。由于谷歌是最流行的浏览器，他们可以确保它默认兼容。由于他们制造了最流行的移动操作系统，因此他们可以确保它也能正常工作。由于他们运行最流行的电子邮件服务，他们可以确保这项技术具有相关的用例。

比必要更开放

当然，谷歌本可以利用这一地位为自己在市场上提供竞争优势，但他们没有。这很酷。每个人都需要这种级别的保护，包括 Yahoo 和 Microsoft 及其竞争电子邮件产品。很酷的是，它的设计使得即使是竞争对手也可以安全地把它变成自己的。该技术与谷歌没有任何关联——甚至硬件也完全与使用无关。

该系统的设计假设您不会将其仅用于 Google。该协议的一个关键特性是令牌在任何时候都不会标识自己。事实上，规范指出，选择这种设计是为了防止创建“超级cookie”的可能性，该“超级cookie”可用于在串通服务之间跟踪您。

因此，您不仅可以在 Gmail 上，还可以在任何其他支持 U2F 的服务上获取单个令牌并安全地使用它。这给了你更多的理由放下钱买一个。由于 Yubico发布了 PHP、Java 和 Python 中服务器软件的参考实现，因此即使是小商店也可以安全地在您自己的服务器上启动和运行身份验证。

U2F 能够使用使用公钥加密的加密通道来确保只有正确的服务器才能获得一次性令牌。这意味着在网络钓鱼网站上插入它意味着什么都不会发生 - 他们无法进入您的帐户。相反，他们不得不依赖 XSS 和本地恶意软件等技术攻击。

它应该能够隐藏您将同一设备用于多种服务的事实，因此同时控制站点 A 和站点 B 的人无法看到您在两者上都使用了相同的设备。它应该是安全的。

它似乎是现在可用的最佳选择，主要是因为正在进行的标准化过程以及对它的广泛支持和动力。

来自FIDO 规范

在向在线服务注册期间，用户的客户端设备会创建一个新的密钥对。它保留私钥并将公钥注册到在线服务。身份验证由客户端设备完成，通过签署质询证明拥有服务的私钥。客户端的私钥只有在用户在设备上本地解锁后才能使用。本地解锁通过用户友好且安全的操作完成，例如滑动手指、输入 PIN、对着麦克风讲话、插入第二因素设备或按下按钮。

我还没有完全探索规范。但：

1. U2F 与 OTP 有何根本不同？
   U2F 没有使用 OTP。它实际上是关于站点身份验证并使用拥有私钥作为一个因素。

2. 与 OTP 系统相比，U2F 如何影响网络钓鱼攻击的可行性？
   有时限的 OTP 系统在打击网络钓鱼（窃取凭据）方面做得非常出色，因为它们很难被窃取。U2F 真的是为了对抗 MiTM 攻击。

3. 针对 U2F 的非交互式攻击（例如暴力破解等）的可行性如何？
   蛮力攻击不会真的是要走的路。您可能想从服务器或客户端窃取密钥。它如何处理恶意软件等是关键。实施将非常重要。

4. 我可以安全地使用具有多个独立服务的单个 U2F 令牌吗？
   当然——这就是为什么公钥/私钥比共享密钥更好的原因。

5. U2F 与其他商业产品相比如何？有没有更好的解决方案？
   我只能和我们说话，我们的商业版本和开源版本都有。主要区别在于我们将目标站点的 ssl 证书的哈希值存储在身份验证服务器中，并使用由身份验证服务器的私钥加密的 OTP 交付。在用户获得 OTP 之前，软件令牌通过用户的连接获取目标站点的证书，对其进行哈希处理并比较两者。如果它们匹配，则显示 OTP，将其复制到剪贴板，并将浏览器启动到 url。如果他们没有给出错误。

   因此，不需要更改服务器或浏览器。密钥存储在与 Web 服务器不同的服务器上。OTP 是流程的一部分（尽管它可以被删除/隐藏）。它是开源的。另一方面，U2F 确实有发展势头，尽管它是一个“付费游戏”财团。U2F 可用于某些“安全”硬件产品。我们的可以在它们上实现（例如，加密 USB 驱动器）。YMMV。

   有关 WiKID 的相互身份验证的更多信息在这里：https ://www.wikidsystems.com/learn-more/technology/mutual_authentication和操作方法在这里： http: //www.howtoforge.com/prevent_phishing_with_mutual_authentication。

我刚刚阅读了一些规范，因为我想知道设备是否存储了实际的（私有）密钥。我可以尝试回答一些问题。

OTP 只是一次性令牌，而 U2F 基于公钥加密；更具体地说，Yubico Fido U2F 密钥似乎使用了椭圆曲线密码学。

U2F 应该有助于防止网络钓鱼攻击，因为您必须通过手动干预来确认交易，即按下按钮。窃取密钥需要窃取设备本身，这可能比 OTP 引脚更难，具体取决于人们存储这些密钥的位置。当然，这两种方法仍然有些容易受到中间人攻击；如果攻击者能够以某种方式在您和服务之间进行干预，干扰正在进行的会话，那么就无能为力了。流量应该加密，端点验证并且没有人应该完全访问您的计算机；显而易见的东西。

我想破解 U2F 密钥的可行性将取决于在特定硬件密钥上实现的公钥算法的强度。Yubico 密钥似乎在 P-256 NIST 椭圆曲线上使用了 ECDSA。判断自己的位数（和曲线的来源）是否足够安全和​​可靠......

FIDO 的概述文档提到了“廉价 U2F 设备”，它不存储实际的私钥，而是将它们加密（包装）存储在“密钥句柄”中，这是将私钥和公钥链接在一起并发送到远程服务。因此，如果我理解正确，远程服务会同时获得公钥（原样）和私钥（在密钥句柄中加密），因此安全性真的取决于硬件设备上使用的算法的安全性；远程站点有你的私钥！在某种程度上，这与将用户会话加密存储在 cookie 中相反——这里远程站点保存密钥，其中私钥部分被加密，理论上只能由硬件设备解密。有趣的是，这个 Yubico 设备本身似乎就是这样一个设备，即

我理解经济和易用的动机——在这类设备的芯片上存储大量密钥对会更昂贵——但我不确定我是否喜欢这种方法。

因此，回到您关于将令牌与多个独立服务一起使用的问题：设备可以生成任意数量的对，因为密钥对保存在服务本身上。当您登录时，设备会解开私钥并检查签名。该消息包含来源，因此密钥应仅适用于该特定服务。

出于高度安全的目的，最好使用存储私钥（或生成私钥）的设备，使其根本无法检索，并且永远不要离开设备。我对这些设备的电子方面一无所知，但我认为它需要一个非常老练的攻击者来窃取然后破解物理硬件以获得密钥，假设设备使用与现代智能卡相同的芯片、模拟人生和其他形式的硬件加密。

资料来源：

• 一般概述：“7. 允许使用廉价的 U2F 设备”

• 实施注意事项：“U2F 令牌可能不存储私钥材料，而是可能导出封装的私钥作为密钥句柄的一部分。”

• 还要检查FIDO“原始消息格式”文档。