我喜欢这个主意，但我也有很多问题悬而未决。请不要将此视为任何形式的抨击，因为我写它是为了将我的身份验证经验应用于这个新方案。

我担心（不分先后）：

1. 未经授权使用私钥
2. 丰富的客户端支持（Outlook、Notes 等）
3. 从多台计算机使用
4. 私钥保护或加密（在客户端）
5. 密钥生成请求的身份验证
6. 隐私

详情如下。首先是一行总结（粗斜体）和一些说明。

1. 未经授权使用私钥

私钥将受到客户端的保护，具有不同程度的安全性。

我担心任何私钥都会在未经我同意的情况下被使用。尝试进行身份验证时，将进行签名操作。我必须在使用前得到提示，否则恶意脚本可以让我的浏览器签署登录票并提交。流氓脚本可能来自小部件、添加或其他 XSS。这种机制的实现会在每个浏览器中有所不同，甚至在同一浏览器的不同平台上，或不同版本等。由于视觉上有些不一致，用户被引诱批准登录请求的风险更大。

2. 丰富的客户端支持（Outlook、Notes 等）

它旨在与网络邮件帐户一起使用。企业“胖”邮件客户端有些落后。

要使浏览器 ID 工作，您需要一个支持它的浏览器。与此同时，一些 browserid.org 发布了“JavaScript shim，它使用标准 HTML5 技术和在 JavaScript 中实现的加密例程来实现缺失的功能”。

企业环境中使用胖邮件客户端（Outlook、Notes、Thunderbird）的用户将是后期采用者，因为该协议也必须在这些客户端中实施。更不用说 Outlook 不与 Firefox 或 Thunderbird 与 IE 共享密钥库。

3.从多台计算机使用

它导致私钥的扩散，因为该方案没有中央权威。

还有一个流动性问题。我必须为我使用的每台计算机注册（生成私钥）。我将如何删除互联网信息亭或借来的计算机中的私钥？即使只有一台计算机，我将如何撤销存储在被盗计算机中的密钥？由于对于单个用户，多个签名密钥都是有效的（因为我的每台计算机都有自己的有效私钥），从服务提供商的角度来看，任何由已知权威签署的访问令牌都必须是有效的。

4.私钥保护或加密（在客户端）

对密钥的访问必须经过身份验证，这会将密码带回图片中。

它可以受密码保护（限制其恶意重用），但如果我在某处更改密码，除非我使用一些基于浏览器/云的同步网络，否则它不会同步。记住密码有点违背了这个方案的目的。很有可能会使用相同的密码来保护每个密钥，就像现在使用相同的密码来验证多个网站一样。

5. 密钥生成请求的认证

访问请求和密钥生成之间存在差距，攻击者可以将其用于网络钓鱼。

我不清楚电子邮件提供商/证书颁发机构将如何处理 CSRF 问题。他们如何知道密钥生成请求是合法的？我的垃圾邮件文件夹会充满证书生成请求吗？还是只使用 DKIM 电子邮件服务器发布密钥？如果请求在发送到服务器的 SMTP 方式上被截获，可以修改吗？

6. 隐私

使用标签允许 browserid.org 打破同源策略。

并且使用脚本标签来包含 browserid.js 允许他们绕过同源策略。BrowserID.org 将（有权）了解您的每次登录尝试。或者您必须自己托管脚本（假设它是自包含的），如果/当其中发现安全漏洞时升级它。

Stack exchange 也有BrowserId 和 WebID的详细对比。正如所争论的那样，BrowserId 非常接近WebID（W3C 的一个 W3C 孵化器组）。以下是在保护这两种协议时通常需要注意的一些要点，因为它们与公钥加密的通常完成方式非常不同。

1. 未经授权的脚本使用 key。同意这需要由 BrowserID 人员非常仔细地实现。由于 WebID 依赖于已经存在 13 年的内置浏览器证书，我认为这部分已经处理了很久 :-)
2. 如果您想要Rich Client 支持，请使用 WebID。它只需要一个 TLS 层——在服务器端稍作调整。所有操作系统和所有编程语言都内置了 TLS。
3. 从多台计算机使用：BrowserID 和 WebID 都允许您拥有任意数量的证书，每台计算机一个。这不是问题。对于 WebID，请参阅此视频WebID 创建和使用 4 分钟

4. 客户端上的私钥加密：所有现代计算机都带有一个钥匙串，用于存储您的密码和密钥，并受密码保护。

   操作系统供应商可以做很多工作来提高这里的安全性。在 OSX 上，我被要求输入一个特殊的密码，我可以或多或少地让不同的工具访问钥匙串。当然，钥匙串永远不应该泄露私钥。提供公钥当然不是问题 :-)

   但当然，对于台式机，人们可以走得更远，使用视频 Cryptokeys、WebID 和 Internet Cafes中所示的加密密钥 ——尽管这需要浏览器供应商在一定程度上改进 UI。在这里，您有一个硬件令牌来保证私钥没有被复制。无论如何，对于 BrowserID，他们需要将其集成到钥匙串中，或者找到一种 JavaScript 方法来通过网络发送存储在钥匙串中的 x509 证书。

5. 密钥生成请求的验证：使用电子邮件是实用的，但本质上是不安全的。仍然有人在使用它，BrowserID 的优势在于它可以与它一起使用，而不需要人们升级到 TLS。WebID 贯穿 T​​LS，因此您可以立即获得商业级安全性。
6. 隐私：我自己对 JavaScript 不是很擅长，并且把它列在我要学习的东西的清单上——只是现在用 Scala 玩得太开心了。无论如何，我不能用 BrowserId 评论这个 JavaScript 问题——但想更好地理解它。使用 WebID 目前不涉及 JavaScript，因此无需处理同源策略问题。身份选择直接在浏览器中，如上面提到的视频中所示。

天啊！我应该再次在这里创建一个帐户来发表此评论！难怪 Facebook 已经摧毁了博客圈。在那里，您只需要 1 个密码，您就可以评论您想要的所有内容。

我正在提交对已接受答案中六点的回复作为新答案......

1. 未经授权使用私钥

在 Javascript BrowserID 实现的情况下，私钥存储在login.persona.org 域下的本地存储中。因此，必须在该域上托管恶意脚本才能访问它。托管在别处的脚本只能通过受限的基于PostMessage的 API 间接访问密钥。

2. 丰富的客户端支持（Outlook、Notes 等）

BrowserID 适用于任何电子邮件帐户或邮件客户端。Javascript shim 用于支持没有本机实现的浏览器。无需向邮件客户端添加任何内容。

3.从多台计算机使用

这里要指出的重要一点是密钥是短暂的。如果您在 Internet 自助服务终端上，密钥的有效期仅为 1 小时，如果您在自己的设备上，则密钥有效期为 1 天。如果您仍然通过 login.persona.org 进行身份验证，则会在过期后根据需要生成一个新的。无需备份。

如果您想清除您的私钥，只需清除 cookie（这也会清除本地存储 - 存储密钥的位置）。

如果您的计算机被盗，则有一个小窗口，在此期间攻击者可以使用密钥，但只要您在 上更改密码login.persona.org，login.persona.org就会失效，小偷将无法获得新密钥。

4.私钥保护或加密（在客户端）

为了获得由您的身份提供者签名的新密钥，您需要对其进行身份验证。如果该身份验证过期，则您需要再次输入密码。这类似于基于 cookie 的会话，这似乎是网络上的常态。

私钥并不是那么有价值，因为它是短暂的。在这方面，它与 cookie 的共同点多于 X.509 客户端证书。

5. 密钥生成请求的认证

身份提供者知道请求是合法的，因为用户通过了他们的身份验证。后备身份提供者仅在确认电子邮件地址的所有权后才签署密钥（以标准的“向用户发送带有随机令牌的链接以单击”方式）。

证书生成/签名通过 Javascript API 在浏览器和身份提供者之间发生。它不是基于发送电子邮件，因此用户不会收到除后备身份提供商在帐户创建时发送的“请确认您的电子邮件地址”消息之外的任何电子邮件。

6. 隐私

一旦 API 足够稳定，其他人就可以include.js自己托管。现在，我们建议不要这样做。

persona.org 可以看到您登录的网站的另一点是使用在线验证工具https://verifier.login.persona.org/verify。一旦确定了数据格式，我们将鼓励人们自己验证断言（例如使用开源库），并且persona.org不再获取这些数据。

BrowserID 旨在成为一个完全去中心化的协议，以实现真正的隐私。但是，它还提供了集中的回退，以解决当前缺乏本地支持的问题。

与某些替代方案相比，当前形式的 BrowserID 的一个缺点是除了核心功能之外的任何事情都很困难：进一步发现信息需要其他协议，例如 WebFinger，而例如 OpenID URL 可以提供链接。例如，很难从 BrowserID 获取显示名称或个人资料图片（尽管由于 BrowserID 为您提供了电子邮件地址，您可以从 Gravatar 获取后者）。

要添加到列表中的另一种竞争协议：WebID：http ://webid.info/