我有一个 Web 应用程序，并且我已经对浏览器进行了检查，以确保用户只设置强密码。我们打电话检查安全漏洞的一家公司指出，这还不够，因为使用一些黑客攻击用户可以忽略检查并设置弱密码。
我不明白这怎么可能是一个安全漏洞。为什么有人会为了设置弱密码而破解安全检查？足以破解 Web 应用程序的专家将理解使用强密码的重要性。
我能想到的唯一原因是，非常非常懒惰的人可以决定破解支票只是为了让密码更容易记住。我不知道这种情况的可能性有多大。
我知道您不能在客户端强制使用强密码，如果在任何情况下都需要使用强密码，则必须在服务器端进行。
我的观点是：鉴于，为了获得可接受的用户体验，我们必须在客户端进行检查，必须有充分的理由，一个真实的用例，可能会产生漏洞，以证明重复检查是合理的服务器端。
阅读答案，到目前为止，似乎唯一可以创建漏洞的用例是当 javascript 不起作用时。这对我来说似乎不是问题，因为默认情况下禁用提交按钮。
您假设检查被故意绕过。可能有人正在使用无法正确处理脚本或禁用脚本的浏览器，甚至可能不知道这一点。
您似乎有理由让人们使用强密码。如果你这样做了，为什么要接受人们可以绕过它呢？
从可用性的角度来看，客户端验证可能会有所帮助，但如果您决定需要最低密码强度，您应该通过在服务器端实现它来强制执行它。
编写服务器应用程序时的规则就是永远不要相信来自客户端的东西。客户端完成的检查非常棒，因为它们通过漂亮的弹出窗口和即时显示提供了良好的用户体验。但由于任何事情都可能发生，从禁用的 javascript 浏览器到使用脚本语言模拟浏览器的用户，所有检查都必须（再次）在服务器端完成。
如果只是建议使用强密码，请执行您想要的操作，如果需要，您必须实施检查服务器端。
顺便说一句：您作为开发人员可以提出解决方案，但客户确实表达了要求。如果您不同意他们的意见，您可以要求澄清并提出其他方式，但最终客户将决定。
如果用户必须设置强密码，仅在客户端检查密码强度是一个漏洞。
如果您在一家大公司工作，并且您必须每 2 或 3 个月更改一次密码，那么一些人将开始绕过客户端对密码强度的检查，以使用更短或更好的密码来记住密码。如果这些密码用于派生加密密钥，例如用于文件的多用户加密，它变得可怕......
始终检查服务器的密码强度，并可选择检查客户端的密码强度以减少对服务器的请求。
基于Teun Vink 的回答，在现实世界中存在一些用户可能不小心绕过安全检查的场景。
假设用户下载了Adblock Plus或uBlock Origin之类的广告拦截器。然后，由于脚本配置错误，其中一个广告拦截器意外阻止了您用来验证密码安全性的脚本。现在用户可以输入1234作为密码，而无需任何服务器端检查来防止它。
或者，也许本地缓存为用户提供了旧版本的脚本。也许他们已将您的网页保存为桌面上的静态 HTML 文件。也许用户的 PC 有病毒，它改变了脚本的内容。俗话说...
永远不要相信用户。
编辑：另请参阅“当 maps.googleapis.com 被阻止时无法保存个人资料”，以了解为什么您永远不应该信任用户的一个很好的例子。