当盐存储在哈希旁边时，您可以破解哈希密码吗？答案

【问题标题】：Can you hack a hashed password when the salt is stored next to the hash?当盐存储在哈希旁边时，您可以破解哈希密码吗？
【发布时间】：2011-10-23 16:09:50
【问题描述】：

好的，所以我一直在阅读（很多！）关于安全性以及关于散列、加盐、加密等的全部内容，而我一直看到的东西真的让我很烦恼。似乎很多人似乎真的知道他们的东西一直说可以将带有哈希密码的盐存储在数据库中。

我不禁想知道，为什么？如果你的数据库被转储了怎么办？他们可以访问所有内容，对我来说，这意味着他们可以查看任何一条记录，瞧（！）旁边就是散列密码和纯文本盐。这为他们提供了针对彩虹表和/或字典攻击运行它所需的信息，不是吗？

我一定是错过了什么（是的，以前从未发生过！）并且真的很想在这件事上得到一些启发。

【问题讨论】：

标签： passwords hash salt

【解决方案1】：

Rainbow 表对一组不同加盐的密码无效，即使盐是已知的；您必须为每种盐构建一个不同的表，这违背了彩虹表的全部目的。攻击者单独暴力破解每个密码会更快。这是为每个用户设置盐的目的。

换句话说，彩虹表仅在您尝试使用相同的摘要算法破解许多以相同方式摘要的密码时才有效。为每个密码添加不同的盐意味着密码不都以相同的方式消化。

【讨论】：

啊，我明白了！但是暴力破解呢？我的意思是为什么把盐留在那里供他们使用？再说一次，我知道我一定错过了什么。
如果密码足够长，暴力破解密码可能需要很多年。添加盐的目的是防止攻击者在几分钟甚至几秒钟内获取包含 100,000 个用户的数据库并发现其中 1,000 个用户的密码。相同的数据库但具有每个用户的盐可能需要攻击者数年才能破解 first 密码。攻击者不太可能花费这么多时间来获取一个密码。对每个密码进行不同的加盐基本上可以防止攻击者有效地重复使用工作。
请注意，有些系统使用单一的站点范围的盐。如果攻击者能够获得该盐，那么他可以构建一个特定于该盐的彩虹表，然后有效地尝试攻击您的密码列表。这就是为什么推荐随机的 per-user salt 的原因。这不是关于防止发现您的用户的凭据（如果您的所有数据都被泄露，没有任何事情可以做到这一点），而是让它变得非常耗时攻击者，他甚至没有尝试。（或者，如果他足够愚蠢去尝试，会浪费大量时间而没有结果。）
现在说得通了。所以这听起来更像是为了阻止对整个数据库的攻击，迫使黑客专注于个人账户，对吧？编辑：你已经回答了，非常感谢！！
基本上，是的。一些网站甚至实现了多轮摘要。例如，如果您对摘要函数进行 100 次传递（将输出反馈到函数中），那么您并不会真正增加站点负载，因为身份验证可能不会成为您站点的瓶颈。（通常是磁盘 I/O 或内存。）但这会导致暴力攻击需要 100 倍的时间。出于这个原因，甚至有一些专门为 CPU 和内存密集型而设计的摘要算法。