【问题标题】：Is the password weak under dictionary attack字典攻击下密码弱吗
【发布时间】：2009-10-18 06:12:39
【问题描述】：

感谢收看。所有真诚有用的答案都被投票赞成。

我使用密码强度计让用户知道他们选择的密码有多强。但是这个密码检查器显然没有涵盖密码在字典攻击下的弱点。我该如何检查，是否值得？

我的常规密码检查器最初在浏览器中使用 javascript 运行（无需传输）。如果我想检查字典攻击弱点，我必须将其传输到脚本。我的理解是我不应该清楚地传输它。

谁能帮我解决这个问题。如何检查密码在字典攻击下是否不弱以及如何在传输到我的脚本之前对其进行加密？

额外信息：

为什么我认为除了常规密码表之外还需要字典攻击检查？正如你们中的一些人所指出的，用户可以选择像 P@ssword 或 Yellow12 这样的密码。但是我遇到的大多数密码强度检查器都会将此视为一个好的密码。至少我正在使用Yet Another Password Meter 并且确实如此（我实际上认为它是更好的密码检查器之一。）如果有人知道更强大的密码检查器，请提及它，但前提是您根据经验确定它更强大;)

但我的问题确实是：我如何对密码进行字典攻击检查？我在某处读到它是针对哈希完成的，但我在哪里进行搜索？一旦我知道如何去做，我就会决定它是否值得。

感谢迄今为止提供帮助的所有人:)

【问题讨论】：

感谢您使用另一个密码表。我正在考虑包含一本基本词典，但我想让它保持快速且易于下载。随意获取代码并进行修改。如果您有一个好的和快速的解决方案，我很乐意提供。

标签： security encryption dictionary passwords brute-force

【解决方案1】：

意见会有所不同，有些人会说检查字典单词很重要。我不同意，而是赞成要求不同大小写的字母、数字和特殊字符，如!@#$%^&*()_-=+。显然密码应该区分大小写。

字典攻击因数字和特殊字符的存在而不太可能成功。假设有 1000 个常用密码。现在，通过添加所需的大写字母和特殊字符，假设用户是“懒惰的”，他们选择将第一个字母大写并在末尾添加一个特殊字符。 1000 大小的字典现在超过 30,000。

此外，还应设置帐户锁定以避免字典攻击。并且可能会限制 IP 地址尝试登录的频率，具体取决于您的应用程序。

在运行脚本时，可能仍然需要避免使用一些非常常见的密码。例如，我不允许密码 p@ssword 一词或任何密码变体。

编辑：验证码虽然被大多数人（包括我）讨厌，但在几次登录失败后也可能是合适的，以避免暴力登录尝试。

【讨论】：

是的，但是 p@ssword 示例违反了典型的大小写混合、数字和符号的要求，并且如果您不允许连续重复字符，那通常对于密码来说已经足够了。如果不是，那么您可能需要生物识别或 2 因素身份验证。 :)
正确，我应该在我的例子中说 P@ssword。我想我得到的是按照将@更改为a和0更改为O的方式做一些事情，并且根本不允许密码忽略字符大小写。我同意，要求混合大小写字母、数字和特殊字符就足够了。我可能不应该提到它:)
您提出了 p@ssword 示例。这正是我认为我需要字典攻击保护的原因。大多数密码强度检查器（即使是好的密码强度检查器）都会将 P@ssword 或 Yellow12 之类的东西评为好。
JavaScript 文件中不可接受的密码的简短列表不会真正造成任何伤害。像这个列表pcmag.com/article2/0,2817,2113976,00.asp 之类的东西，也许同时再次将@ 规范化为 a 和 0 到 o，等等。我不会浪费任何时间尝试从字面上检查整个英语词典。

【解决方案2】：

我比其他问题来得晚，我很惊讶没有人指出字典检查可能不是详尽无遗的。至少没有人说过这么多话。

我认为您需要一个大字典，其中每个条目都经过哈希处理并与 哈希处理 密码进行比较。这将允许您说用户选择的密码在您的字典中不是，但是您如何确定它是完整的？

显然，您无法确定。你包括外来词吗？技术词汇？

密码破解者可以使用更好的字典吗？

我认为你所能做的就是建议用户如何创建一个好的密码——给他们看几个例子——但让他们自己选择。

然后做 SSL 的事情。

【讨论】：

好点。也许完成字典攻击检查需要大量处理。我现在正在重新考虑。

【解决方案3】：

还有一点 - 如果您控制了网站，您可以通过限制用户尝试用户/通行证的次数来阻止字典攻击。

很高兴您希望您的用户拥有更好的密码，并且您应该继续朝着这个方向前进，但是对于字典/暴力攻击的更好解决方案将是对登录尝试失败的指数退避解决方案。没有真正的用户会尝试在 10 秒内使用所有不同的密码登录 1000 次。

【讨论】：

【解决方案4】：

如果您使用适当的复杂性要求（长度、大小写混合、数字、符号，并且可能禁止连续重复一个字符），那么我会说这并不值得。如果您处于需要这样做的情况，那么密码身份验证可能无论如何都不足以满足您的情况。

【讨论】：

【解决方案5】：

SSL

如果您的网站以任何方式或在任何页面上请求敏感的个人信息，包括密码，那么您应该在整个网站上启用并强制执行 SSL。这将确保所有密码都以加密形式从浏览器传输到服务器，并且没有人可以从网络上嗅出密码或修改传输中的页面（并更改表单回发网址）。

密码计

您应该完全在浏览器中运行您的密码计。您应该接受用户输入的所有密码（最短长度为，例如 6 个字符），但可以在浏览器中随意提示用户，无论他们输入的是弱密码还是强密码。

【讨论】：

我还要澄清复杂性检查应该在服务器端进行，因为可以绕过 javascript 和其他浏览器脚本语言。因此，您肯定需要 SSL 将其发送到服务器。密码仪表很不错。
我的意思是您不应该进行复杂性检查。相反，您应该允许使用弱密码。您应该使用 JavaScript 简单地通知用户密码很弱（但用户仍然可以使用它）。唯一的服务器端检查应该是最小长度/最大长度检查（最小和最大长度都应该足够大：可能是 4 和 40）。
但您可能要求只允许使用复杂的密码。如果这是您的业务逻辑的一部分，那么您当然应该在服务器端进行检查。但是，我同意，如果您在这个阶段，您应该使用 SSL。
正确。如果出于商业原因要求密码具有某些类型的复杂性，那么您将必须在服务器端（也许还有客户端）实现它。但通常，这些商业原因是愚蠢的，其最终效果是降低您网站的安全性。