为什么PAKE或零知识密码证明没有取代通过HTTPS发送密码

Question

像零知识密码验证和派克这样的技术似乎相当成熟，但是几乎所有的现代网站仍然通过HTTPS发送密码来检查身份验证。乍一看，这个协议看起来像一颗神奇的药丸，但仍然没有被采纳，我想知道为什么。

Answer 1

最简单也是最正确的答案是，没有充分的理由这样做。您不会以这种方式添加任何重要的安全性；除非您的服务器或客户端被破坏，否则截获TLS传输的密码的可能性非常低，但是如果客户端被泄露，则可以直接抓取密码，如果服务器被破坏，攻击者几乎不需要密码，而且(在网站的情况下)可以为直接收集密码的修改页面提供服务。确实，这个答案并不完全正确，原因是登录错误或收集密码以便在非web应用程序上重用等等，但诚实的事实是，这些问题中的大多数都不值得花费很大的精力去打败。在安全工程方面，ZKPP缓解的威胁，但TLS和其他标准实践并没有减轻的威胁并不是什么大问题，所以威胁模型说ZKPP并不重要。还值得注意的是，ZKPPs实际上并不能完全减轻风险，比如不正确的日志记录；如果日志是由客户端生成的(对于现代应用程序来说，很多日志都是这样)，它们可能仍然包含密码。

另一个原因，正如您的PAKE链接所指出的，是因为没有太多的实现。TLS很容易使用；每一种重要的编程语言要么在标准库中支持它，要么有支持良好的绑定到库实现(通常有几个)。在最坏的情况下(或者在脚本编写时)，您可以使用管道或其他IPC来使用启用TLS的通用工具，如curl或openssl。然后服务器需要散列值，但同样适用于此；许多标准实现和第三方库实现在更新的构造中或绑定到~每一种语言中，它们通常很容易找到用于和使用的文档。相比之下，PAKE (或任何ZKPP)的实现并不多，而现有的大多数实现都需要额外的开发人员的努力来定位实现和文档，然后更努力地使用，而TLS (您几乎可以肯定地使用TLS)的熟悉和简单的选项加上密码散列。在当今快速发展的世界里，这是一个有意义的代价，只有当它减轻了一个有意义的威胁时，这才是合理的。

最后，还有帐户注册和密码轮换的问题。这通常只适用于“平衡的PAKE”和类似的实现，在这些实现中，双方都需要知道密码，但其他一些ZKPP也有问题:如何告诉服务器它应该从用户(或用户应该发送什么密码)那里获得什么密码，而不通过网络传输密码(以一些明文或可逆加密的形式)？显然，我们不应该让完美成为好的敌人，在这里，减少密码直接传输到帐户建立和密码重置/轮转的时间比每次登录都要好。但它仍然付出了增加复杂性的代价，而且收益也比预期的要少。

尽管如此，不透明地将昂贵的密码散列卸载到客户端(而不使任何服务器持有的数据成为密码等效的)的能力是不错的。当然，您也可以使用简单的密码-hash-over来实现这一点，但是您仍然必须在服务器上再次散列，否则服务器的DB最终会保存密码等效值。在我看来，对ZKPP来说，这是一个引人注目的优势。也许有一天，会有一些公共库使其易于使用、不透明，或者成为密码散列库的后继库，从而使通过TLS发送密码的bcrypt或argon2更容易使用。

Answer 2

有几个问题，我将在下面详述。有些比另一些重要得多。我还应该指出，我在2015年下半年1 1Password部署SRP方面发挥了作用。

1. 简单的基于密码的身份验证很容易实现。不需要做任何新的工作，也不需要部署客户端。
2. 专利不确定性。在美国的一些专利过期后，帕克变得更受欢迎。
3. TLS得到了改善，并得到了更广泛的推广，因此帕克解决的大部分问题(但不是所有问题)都已由TLS解决。

通过讨论我们在七年前开始使用PAKE (SRP)时所经历的1 1Password，来说明这些要点可能是最简单的。

TLS与PAKE

的比较

我们，1 1Password，有TLS没有提供的身份验证的安全性要求。但是，这些安全要求可能不是每个人都能共享的。

首先，我们从未想过要接收用户密码。在传统的密码身份验证(通过TLS)中，服务接收密码，对其进行散列处理，并将散列与存储的内容进行比较。即使服务立即抛出未清洗的密码，它仍然接收到它。在一个典型的服务上，这并不是很糟糕，因为无论如何，服务本身都可以完全访问。但是在我们的例子中，用户的密码可以被用来解密他们的数据，这是我们从未想过要做的事情。因此，对于我们来说，用于身份验证的用户秘密(与)用于解密数据的用户秘密有关，零知识更为重要。

然而，对于典型的服务，零知识的需求减少了.拥有未散列密码服务器端并不会增加该服务器的功能。恶意服务器可以利用知道用户的密码，试图通过密码重用而危害其他服务，但它不会给自己增加对自己的服务的权限。

我们还想要比TLS所提供的更强大的相互认证。使用PAKE，服务器还可以证明它知道客户端的特定用户秘密。TLS向客户端提供了服务器域名的一些身份验证，即使这样也不像我们所希望的那样可靠。

最后，我们希望有一个会话密钥，用于对消息进行加密和身份验证，以将该密钥与身份验证过程联系起来。客户端和服务器之间的消息以加密方式绑定到来自PAKE的身份验证。

所以对我们来说，我们有TLS没有提供的需求。当然，对于更典型的服务来说，这“很好”，但可能不值得付出这么大的努力。

Implementation

当时，我们不得不用五种不同的语言将PAKE客户端代码编写成五个不同的代码库。即使今天有更好的库可以链接到不同的客户端，它仍然是一个问题。当然，这意味着是部署客户端的人。并不是每个服务都处于编写所有客户端的位置。

尽管在过去的七年里，事情变得更容易了，但这并不是一个切换到使用PAKE的问题。但是，建立传统的用户名/密码系统很容易，很熟悉，不需要在客户端中添加和维护复杂的代码。

专利

有许多美国专利可以被解释为适用于(许多)帕克人。如果你和最终法院认为你对它们的使用是不侵权的，这并不重要。专利巨魔仍然可以使你的生活悲惨，并勒索你的钱，如果他们认为他们有最轻微的暗示，一个小案件。软件专利是有毒的。

一项可能被视为覆盖SRP的专利于2015年5月到期，尽管SRP旨在避免专利问题。另一项重要专利于2017年3月到期。

尽管世界上有很多地方没有这些专利申请，但没有人想要为美国境内使用的客户建立一个需要不同认证方案的系统。

其结果是，在帕克斯最初发明之后的几十年里，他们的部署很少。在这段时间里，TLS解决了帕克解决的一些最相关的问题。

PAKEs

的未来

我喜欢帕克斯，我希望他们能更早地被广泛使用。但我怀疑WebAuthn/passkey的变体会降低PAKEs在广泛应用中的相关性。除了其他属性之外，WebAuthn/passkey还提供了许多相同的PAKEs安全属性。总有一些地方的密码是不合适的，并且PAKEs将继续扮演一个角色；但我不认为PAKEs将成为大多数传统用户名/密码身份验证的接班人，因为密码将涵盖这一点。PAKEs和传统的身份验证总是有其作用的，但是密码将是最主要的技术。