Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 个赞
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 个赞
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 个赞
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 个赞
这让我无法理解（因此我顶了这篇帖子）：一旦某个密码被确认已被破解（或以明文形式被发现），其安全性就会显著降低。即使采用非常宽松假设，这也代表熵值大幅下降：
- 一个随机的 10 位密码，即使字符集非常有限（例如仅包含小写字母的假想示例：Pr = 1/26^10 = 1/1.4e14）
- 一个已知出现在 HIBP 列表中的密码（Pr = 1/5e8）
关键在于：是当另一个人使用了该密码，并且该密码同时已被泄露和/或解码——这才是关键区别。
那么，阻止一个仅出现在单一列表中的密码，实际存在什么问题呢？作为用户，我肯定希望知道这一点，以便避免再次使用该密码。作为网站管理员，我也不希望我的用户使用已泄露的密码。这似乎完全值得在可用性方面做出妥协。
不，这并不是关键区别，因为从统计角度看，所有密码最终都会在一定时间内被泄露。
请记住，我们多年来一直屏蔽最常见的百万个密码，因此您在真正重要的方面已经得到了保护。
3 个赞
从统计角度看，所有加密和哈希算法最终都会被攻破。一旦有迹象表明某种算法即将被攻破，我们就应停止使用它。
密码为何例外？所有安全措施本质上都是基于这样的赌注：所使用的熵足以应对特定任务，并且其中始终包含对攻击强度或持续时间的假设。
既然密码首次出现在泄露列表中时，其熵值至少会损失 6 个数量级（实际上可能更多），这似乎是一个显而易见的决定。
是的，与当今许多其他软件包相比，这已经是一个好得多的局面。对于希望在现有基础上获得更多保障的网站来说，HIBP 仍然是一个很好的改进。
如果技术上可行，这似乎是一个通过插件添加“生成密码短语”按钮的好机会……
该功能将排除所有出现在“已泄露列表”中的内容，同时用户也可以选择自行创建密码短语，其内置了基础的百万级排除列表。通过按钮方式，用户无需了解“已泄露列表”和熵的概念，因为大多数人通常没有时间去学习这些。
不过，就个人而言，Discourse 目前的表现已经相当不错了。
为什么要在服务器端生成密码？
假设用户需要保存密码，那么让用户自行负责密码生成不是更有意义吗？他们选择的凭据管理器很可能已经具备此功能。
2 个赞
因为这可能比不断告知用户“apple”、“apple1”、“apple 123”、“apple 12345”等密码不符合百万禁用列表要求要好。就我个人而言，我并不会特别期待 Discourse 具备此功能，但如果它能以相对优雅的方式解决“已泄露密码”问题，并在出错时将控制权留给用户，那么或许值得考虑。
您是在暗示客户端密码管理器会生成此类密码吗？
倡导用户使用密码管理器，远比强制要求用户从单一网站设置密码更为有效。后者只会导致用户在其他地方也使用相同的密码，从而加速其被破解。
修复愚蠢比修复被攻陷的问题更难，而采用类似 https://www.useapassphrase.com/ 的做法，在我看来，至少为那些不关心其学术细节的人提供了一点帮助。
我构建的系统已被数千万用户使用，我们曾试点过多种密码管理方案，包括那些令人头疼的“必须包含 x 和 y
3 个赞
我本以为 JavaScript 会在客户端随机生成一个密码短语，然后进行哈希处理并与列表比对。教育部分可以在“为我生成密码”上方作为一个占位符。说实话，我不认为 Discourse 需要操心这些事，但只要人们把自己的行为所引发的愤怒错误地归咎于品牌，那或许还是值得考虑一下。
那么，我认为你最好的办法是开发或委托开发一个能够实现你所建议功能的插件。
1 个赞
这正是该插件的用途。
自从编写这个插件以来，我仔细思考过这个问题，现在我也赞同 Jeff 的观点。
“泄露”意味着有某个地方有人想出了出现在“列表”上的那个短语。想象一下，如果有人创建了一个工具：
- 将字符串列表公开。
- 系统地生成并追加唯一的字符串到列表中。
Jeff 的观点是，这意味着最终，所有字符串都会变得“不安全”，因为它们会出现在某个公开列表中——最终，你那个“超级安全”的密码短语也会出现在这个不断扩大的列表中。
密码本身的整个概念，仅仅依赖于“统计上的不可能性”，即有人无法猜出你的账户密码。攻击者技术上并不需要知道密码，他们只需要做出一个非常准确的猜测。他们可以通过定义什么是“好的猜测”来增加胜算：
- 如果他们掌握了泄露数据，就尝试用相同的密码登录相同的账户。
- 如果他们拥有泄露数据列表，就尝试那些很多人使用的密码。
我们已经讨论过 Discourse 在应对上述第 2 点方面的优势。我认为你想要解决的是第 1 点，但在核心功能中加入类似这样的机制（假设任何与用户名无关的密码都不应被使用）是完全没有必要的，而且会造成严重的可用性问题……但如果你希望在你的网站上实现你所描述的功能，那么这个插件正是为你准备的。
4 个赞
是的。坦率地说，这是一个糟糕的论点，因为它完全脱离了概率的概念，而概率才是推理此类问题的唯一正确方式。
幸运的是，我们讨论的是一个边缘情况，这种情况出现在剔除了最常用的密码之后，而剔除常用密码本身就已经是一个相当不错的策略了。
1 个赞