更强的密码几乎总是比弱密码更好。如果发生泄露，密码的散列和加盐的细节变得非常重要。

如果服务器使用纯文本，那么强密码和弱密码都是一样彻底的。

例如，如果服务器使用了臭名昭著的 Microsoft LAN Manager，哈希字符串密码将无济于事，那么使用高覆盖率彩虹表将立即破解长度为字母数字密码（最大为 14）的密码。一些非常奇怪的特殊字符会有所帮助，但作用不大。

如果该站点使用了适当的安全性，例如加盐 bcrypt 哈希，那么即使使用这样的哈希，目前也没有可行的方法来反转相当强的密码。盐渍化使彩虹表不是很有用，并且 bcrypt 被设计为对蛮力进行缓慢而不是快速合法计算。

然而，site.breached 显然受到了破坏，并且其他站点可能使用不同的密码。如果您使用随机密码，您可能正在使用密码管理器，并且可以为每个站点提供自己的密码。因此，如果它只是更改一个被泄露的密码，那就去做吧。

当出现违规行为时……与使用真正随机密码的人交谈时——例如由优秀的密码管理器生成的密码——可以说你可能是安全的吗？

从理论上讲，是的（在一大堆假设下）。

假设…

• 您是个人（不代表公司、组织或机构）
• 您每次只通过安全连接 (HTTPS) 传输您的密码，
• 被破坏的站点实际上使用了一种经过严格审查的、完整的、加密安全的慢速哈希算法（如 Argon、bcrypt 等）对您的密码进行了哈希处理，
• 该站点仅存储密码哈希（而不是您的纯文本密码），
• 服务器代码不包含可能泄露您密码的安全故障，
• 没有发生其他安全漏洞，也没有成功利用其他攻击媒介，
• 等等。

……最后但并非最不重要的一点是，假设……

• 攻击者不是一个拥有无限内存和处理能力的人，
• “违规”仅限于攻击者仅获取存储密码哈希的数据库副本（而不是某些流氓员工或类似人员）

……那么您的问题实际上可以归结为：“使用彩虹表等攻击随机密码是否更难？”

在这种情况下，在所有这些假设下，答案是“理论上是的”。

与类似字典的密码相比，您的密码会更安全，因为攻击者预先计算字典密码的机会高于攻击者预先计算出乱码序列的机会。如果网站开发人员正确地完成了他们的工作，他们还会使用 salts 等——这使得攻击者的事情变得更加困难，并且在某种程度上使攻击者的所有预计算工作无效。

然而，如果攻击者是一个州或国家，那么这些机会就会减少到接近于零的水平。此外，上述内容依赖于大量假设。像在哈希密码时不使用盐这样的小事情会使事情变得比任何攻击者都希望的更不安全。如果网站后端没有为您的密码使用慢速散列函数（Argon、Bcrypt 等），则会出现类似问题。所有这些都会并且将会对您对随机密码的期望安全性产生影响。

实际上，没有。

当一个站点被破坏时，破坏本身大多只是一个更大的安全问题冰山的一角，并且此类攻击很少将自己限制在一个充满密码哈希的被盗数据库中。

如果您有理由相信您的密码以任何方式被盗或泄露，您应该更改它，并确保在您使用相同或类似密码的所有帐户上更改它。仅仅依靠一个被破坏的网站没有其他广泛的攻击媒介这一事实并不是一个明智的举动。

看……如果发生突破，炸弹的导火线已经点燃。仅仅因为您碰巧有更长和/或更好的保险丝并不意味着您比其他人更安全。它只是为你争取更多的时间，直到事情爆发。如果网站开发人员做对了他们的工作，那么爆炸可能需要几十年的时间……但如果有人设法破坏了网站，那么开发人员很可能做错了什么（如果不是全部的话）。

因此，尽快更改您的密码是万一网站遭到破坏时最安全/最明智的做法。特别是，因为您永远不知道网站程序员可能在哪里丢球，从而在可能会或可能不会影响您的密码和/或其他凭据的安全性的地方引入了其他安全故障。

一般来说，一个好的密码策略会促使您在发生违规时（以及在其他一些情况下）刷新您的密码。此外，作为个人密钥管理的一部分，无论如何，您应该定期轮换（阅读：刷新、更新）您的密码——因为这样做可能“有助于减少某些密码泄露的影响” （但不是全部） . 由于您提到了密码管理应用程序，因此它很可能已经包含相应的功能。即使没有，也肯定比不断怀疑攻击者是否能够恢复您的密码更容易更改密码。

但最后，如果是在使用（让我们称之为）“更随机的密码”时，这是个人意见的问题fair to say，you are probably safe因为这在很大程度上取决于个人场景以及您在写作时的确切含义probably safe。

TL;博士

因此，将所有这些总结在一个最终的结论性答案中：“当攻击者试图反转/破坏捕获的密码哈希时，与其他用户使用的随机密码相比，更随机的密码可能更安全，但你绝对不应该依赖从长远来看，您的密码是安全的。但是，当相关网站遭到破坏时，请更改您的密码，因为安全总比后悔好！” 大多数情况下，网站在检测到违规并填补相关漏洞后，无论如何都会要求您这样做。

与您的问题相关，您可能也有兴趣查看ftc.gov文章Time to rethink强制密码更改；尤其是“什么时候应该更改密码？” 部分。