在这种情况下，密码强度是一个毫无意义的概念。在大多数情况下，密码的强度并不是密码本身的固有属性。注册表单中的输入验证逻辑仅根据特定标准检查密码：它有数字吗？它有特殊的性格吗？是否超过 8 个字符？等等。

此类检查可以在客户端的浏览器或服务器上完成。然而，执行这些条件只能在服务器上完成，因为用户可以简单地绕过这些客户端限制。这些检查是在用户的浏览器中完成的，因为在那里进行检查要快得多；它们只是用户的指标。将密码提交给服务器后，必须根据这些条件对其进行检查。

旁注：我不是限制性“密码强度”条件的忠实拥护者，也不推荐它们。但是，我确实看到了检查最小长度并确保密码不存在于字典或单词列表中的好处。

任何一个都可以接受

几点考虑：

1. 从可用性的角度来看，检查客户端的延迟更少，因此对用户更友好。

2. 您可以在服务器端进行更详细的检查。例如，检查密码是否基于字典单词。但是，大多数站点不进行这些详细检查。无论如何，我不相信进行详细检查的好处。检查密码强度的目的只是为了阻止某人使用微弱的密码，仅此而已。

3. 如果您在客户端进行任何验证，则恶意用户可以绕过检查。您通常应该在服务器上重复任何检查。但是，就密码强度而言，我认为这并不重要。如果用户愿意使用交互式代理来允许自己使用弱密码，那么对他们来说公平竞争。到那时，我会让他们一个人呆着。

事实上，我更喜欢使用密码强度顾问，而不是密码强度检查器。当用户输入他们的密码时，一个指示器会显示“弱……中……强”。不禁止他们使用弱密码；他们只是被警告。

在 2018 年编辑最佳实践是现在检查用户的密码是不是在数据泄露中泄露的数百万个密码之一。这只能在服务器端完成。

应该在客户端还是在服务器端评估用户的密码强度？

两个都。

从可用性的角度来看，客户端检查非常有用，因为您可以执行检查，而无需用户向服务器发送任何数据，这会导致延迟损失。这种检查很容易在网络浏览器中使用 javascript 实现。

如果您需要强制执行密码强度策略（可能作为一项或多项规定的一部分），则必须在服务器端执行强制执行。任何客户端检查都可以（相对）简单地绕过。

对 Gmail 的粗略检查表明密码强度分析是在客户端使用 JavaScript 完成的。我通读了他们的 .js 了一会儿，决定在早上 9:30 没有咖啡的情况下它是不可穿透的，并在我输入新密码时用 tcpdump 观察了线路。每次按键都不会触发浏览器和 Google 之间的流量，但是每当密码评估发生变化（例如，从“太短”到“弱”）时，都会出现与小帮助文本气泡变化相关的流量。

您可以在他们的更改密码页面上按 Chrome 中的 F12 并浏览他们的所有 JavaScript。先喝咖啡。

话虽如此，在万维网中，密码几乎总是以明文形式发送到服务器，但最好是通过 HTTPS，以便 SSL 包装器提供安全性。它们要么是 GET 或 POST 形式的纯文本，要么在HTTP Basic Auth 标头中编码（未加密）。为什么？密钥管理。

客户端无法通过密钥来加密服务器共享的密码。设置一个要么需要将密钥分发给 N+1 个客户端并保持保密性......要么设置一个公钥系统。一旦你建立了一个公钥系统，你就踢自己，说“我为什么不从一开始就信任 SSL？”

现在，这里有一些异常值需要考虑：

服务器和客户端可以执行摘要式身份验证。简而言之，服务器发送一个随机字符串，客户端对密码进行哈希处理并将其与该随机字符串混搭并发送回。服务器端需要有正确密码的明文副本；它执行相同的 hash+mash 过程并进行比较。这对于攻击者来说更难获取网络上的密码，但通常需要服务器知道明文密码（而不是散列版本）。

BMC Remedy曾经实现以下功能：登录页面包含会欺骗密码的 JavaScript - IIRC 它存储了一个静态字符串，并使用该字符串对密码执行替换密码。它将修改后的字符串发送到服务器，服务器可以简单地反转替换。唯一的问题？ 任何人都可以反转替换，因为它遵循在登录页面上的 JavaScript 中发布的静态算法。 因此，Remedy-over-HTTP 没有为密码提供真正的保护……这可以追溯到最初的主题，即“我们通常只信任 SSL 来保护传输中的密码”

最后，我知道有一个应用程序——Litle PayPage——使用嵌入的公钥分发 JavaScript。PayPage 接受的不是密码而是信用卡数据，JavaScript在将整个请求包装在 SSL 中并通过 HTTPS 提交之前，使用嵌入的密钥对卡号进行加密。任何应用程序都可以这样做，基本上解决了我列出的与客户端共享密钥的初始问题 - 或复制 SSL 系统，任你选择。这种方法的优点是它回避了“如果 HTTP 网关在 SSL 上执行 MITM 怎么办？”的传统问题。