为何实践中不使用零知识证明？

#1 楼

回答您标题中的问题（而不是解决您提出的我不太理解的替代方法）时，密码协议“ SRP”的零知识证明是快速有效的。

SRP似乎并未得到应有的广泛宣传。实施它并成为其使用的倡导者，我真的不明白为什么每个人都不会一直使用它。我见过的一些理由是：


相信服务器完全是“好”或完全是“坏”，并且使用HTTPS可以确保您始终与之对话“好的”服务器，可以使用纯文本密码进行信任。现实生活不像电影那样；它更复杂。 Heartbleed崩溃表明，一个值得信赖的站点可能正在泄漏内存位，从而使第三方可以观察到通过HTTPS发送的纯文本密码。更为常见的情况是自定义网站代码中的错误处理不善，这些错误会将明文密码输出到日志文件中，而入侵者只能看到服务器上的文件系统，从而可以读取该文件。大型系统将日志准确地流式传输到中央本地，以便更轻松地查看日志中的错误，许多人可以在其中搜索模式。
认为客户端是完全安全的或完全受损的，这样，攻击者就看不到任何东西，其他人则可以记录所键入的内容。如果攻击者可以记录所键入的内容，则他们可以直接窃取密码。 SRP仅防止电线上的拦截，而TLS保护电线。实际上，即使使用配置良好的HTTPS，侦听也要比人们意识到的更为常规。大型雇主通常会对HTTPS进行解密和扫描，以保护自己免受员工盗用智力财产的侵害。即使他们只是为了保护自己的数字产权而这样做，也增加了错误泄露明文密码或流氓员工窃取密码的风险。大型笔记本电脑供应商安装了超级鱼之类的东西来解密客户的HTTPS流量，以在页面上出售“智能广告”。他们可能不是坏人。但这会增加错误泄露密码或流氓员工窃取密码的风险。也有证书被泄露的示例，这意味着可以监听加密的流量。所有这些意味着攻击者常常可能无法直接记录用户在键盘上键入的内容。但即使使用HTTPS，也可以查看通过网络传递的所有内容。 SRP是零知识密码证明，可以防止任何此类拦截。
相信SRP可以替代HTTPS。 SRP（开箱即用）不（在注册时）验证服务器，因此您可能在与假服务器通信。因此，在SRP和HTTPS的“或非或比较”中（假定上面没有详述的问题），HTTPS通常被认为是高级的。这是一个错误的二分法，因为实际上，现实世界中的HTTPS具有许多弱点，可以通过在HTTPS上使用SRP来解决这些弱点。通过HTTPS执行SRP可为您提供服务器验证，从而增强了SRP。因此，人们应该始终同时使用两者。
很多方面都将重点放在两因素身份验证上，作为对纯文本密码的增强。确认密码具有高风险的公司倾向于采用第二个因素（例如，手机上的文字）。该网站可能仍会泄露密码，用户可能会在多个网站上使用该密码，其中许多网站并未使用第二因素。如果站点升级为使用SRP和第二个因素，它们将完全保护其用户。

实现SRP时有两个障碍：


历史上缺少纯JavaScript示例。早期的权威演示使用Java小程序。最近，在Heartbleed崩溃之后，SRP有了复兴，现在有一些可靠的开源JavaScript库和演示。
一次额外的往返登录。使用纯文本，您可以在一篇文章中发送用户名和密码。使用SRP，您首先要发送用户名以获取帮助（以及挑战），然后生成密码证明以发送至服务器。大多数Web安全框架都假定所有内容都是一次往返发送的。可以通过第一次往返的AJAX调用并张贴密码证明作为密码来解决。现在，更多站点将用户名和密码划分为两个页面，以实现“社交登录”。根据您在第一页提供的电子邮件，他们会显示一个密码页面，该页面针对正确的社交登录服务器。这两个页面模式非常适合SRP，并且最终用户越来越熟悉它。

前面已经说完了，没有充分的理由说明为什么每个站点现在都不使用SRP。因此，您对纯文本密码仍在使用感到惊讶是正确的。

更新：我仍然遇到来自加密专家的关于SRP的激进推论，他们认为TLS足够。我敢肯定，只有理论上讲绝不会犯上述错误的高安全性公司才会雇用他们。他们用自己的理论知识击落了TLS和SRP的深度策略中实用的附加防御措施，这一事实令我感到惊讶。由于理论上的原因，我没有成为SRP的粉丝。我刚刚升级的在线银行系统通过完美配置的TLS未能通过渗透测试而使我迷上了，外部测试人员设法收集到了实时密码。正如我祖父告诉我的那样：“理论上，理论和实践都是相同的。实际上，它们不是。”客运航空公司使用冗余来维持人们的生命。安全从业人员应该深入地使用防御，而不是理论上的安全模型。

#2 楼

SRP通过身份验证进行DH密钥交换，并且还具有对服务器进行身份验证的能力（尽管通常通过保持验证者的秘密来对服务器进行身份验证）。如果密钥严格是由密码和盐生成的，并且盐存储在服务器上，则可以对验证程序进行字典攻击（例如，如果服务器受到威胁或服务器是恶意的），但是有一些方法可以增强抵抗力为此。

不进行（非常昂贵的）字典攻击，服务器将永远不会看到密码，并且有各种可能使字典攻击不可行。

更新到回答更新的问题：
如果算法已知，则特定于站点的密钥与其他任何方案一样容易受到字典攻击。

您可以使用两个密码的方法进行加密

示例：
$ MasterKey = HMAC（MasterPassword，Identity）$
$ SiteKey = HMAC（MasterKey，Password，SiteIdentifier）$

其中$ Identity $可以是您想要的任何内容（例如，电子邮件地址，SS＃，昵称）。我使用$ SiteIdentifier $作为某种形式的持久身份。域名可能不够稳定，因此可以使用某种GUID或公钥，也可以使用某些东西。

$ MasterKey $也可以从存储在密钥服务器上的值或在专用设备上（可能仍与主密码结合使用）。有很多可能性。

$ SiteKey $可以直接用作诸如SRP之类的协议中的秘密密钥，也可以像随机密码生成器的工作方式一样变成可键入的密码。

使用SRP，用于标准实现的协议具有服务器提供的盐，可以代替$ Password $使用盐，也可以像通常一样生成可键入的密码并将其与盐组合在一起（尽管需要盐）使用随机密码消除了密码，这将允许通过手动键入生成的密码来将密码与SRP的其他实现一起使用。

#3 楼

让客户端（例如，Web浏览器）使用零知识证明对服务器进行身份验证只有在服务器事先知道客户端的公钥并且客户端永远保持相同的私钥时才有意义。因此，您可以在注册帐户时让客户端生成密钥对，而服务器会记录您的公共密钥以及您的登录信息。然后，您可以使用零知识证明来登录。我认为SSH支持这种身份验证。也有一些第二因素身份验证方法也可以用这种方法工作，但实际上，这麻烦多于其应有的价值。如果出现以下情况，该怎么办：


用户清除浏览器缓存？
用户尝试从另一台计算机登录？
他们的私钥发生了其他错误。

在所有这些情况下，用户将无法登录，并且必须恢复其帐户。

，我想您可以让用户键入他们的密码，然后在客户端使用该密码重新生成私钥。这样，它仍然是基于密码的，您不会丢失私钥，并且可以使用零知识证明进行实际的数据交换。我想到的反论点是，使用密码作为种子不会增加密码的强度，因为攻击者仍然只需要猜测密码，但是每次需要时，您都必须执行完整的RSA密钥生成登录某些内容，这可能需要在移动设备上花费几分钟。大多数人会发现这很令人生气。

关于让服务器以纯文本格式查看密码的观点：是的。这是真的。我不知道该怎么说这就是为什么核心安全专家会告诉您为每个网站使用不同的密码，并使用密码管理器来跟踪所有密码。

#4 楼

实际上，有一些使用零知识证明进行身份验证的SaaS平台，因此最终用户可以向身份验证服务证明他们知道秘密，而无需向验证方透露该秘密。在服务提供者服务器或客户端服务器上没有存储与安全相关的信息，这意味着黑客无法窃取任何信息。

M-Pin使用多因素零知识认证协议，M-Pin的思想是向每个注册的客户端颁发一个大的密码秘密。然后，他们使用零知识证明向服务器证明他们拥有此秘密。这消除了将与客户端机密相关的任何信息存储在服务器上的要求。

您可以在https://www.miracl.com/miracl-上阅读Mike Scott博士的完整加密论文。 labs / m-pin-a-multi-factor-zero-knowledge-authentication-protocol

#5 楼

Sovrin是一个身份分类帐，旨在使用带有零知识证明的可验证凭据进行身份验证。当前，它支持平等性，并为零知识集成员资格的计划提供谓词。加密基于Jan Camenischs基于属性的凭证的工作。发行者在每个凭证中签署这些盲目的属性，并且承诺使每个呈现方式都是唯一的。

#6 楼

但是有一小段时间，服务器知道了秘密


...以及键盘电缆（笔记本电脑的网络摄像头）中的无线错误也是如此和iPhone，卫星的微波麦克风正在窃听击键的声音，等等。如果您担心服务器不能进入Internet（不是服务器，请顺便说一句，BTW-屏幕内存捕获您的密码）是不会从内存中移出...但是保留了可以跟踪和捕获的痕迹），您可以在将密码提供给服务器之前使用智能卡对密码进行哈希处理和添加盐分。


对于其他敏感内容，我可以使用相同的密码。不需要零知识证明吗？


当您开始使用一次性密码垫作为密码学中的多次突破时，零知识证明是您的最小问题。通信线路上的任何启动黑客都可以在早餐时破解您的“相同密码”。