我刚刚阅读了很多关于 SO 的关于使用盐对密码进行哈希处理的文章，但我就是找不到特定查询/困惑的答案。
假设我刚刚完成了向数据库添加密码和盐的方法：
如果这是正确的，当攻击者访问我的数据库时会发生什么？当然，如果他们可以读取该散列密码的盐值，他们可以计算出没有盐的散列密码是什么，然后使用彩虹表？还是用可逆的东西加密盐值也是个好主意？
如果盐值以纯文本形式存储，我就看不到它的意义。请赐教？
【问题讨论】：
标签： database encryption hash salt
如果攻击者进入数据库，那么所有的赌注都没有了，但就盐而言......
盐的意义不是要保密，而是阻止彩虹攻击——彩虹攻击是通过彩虹表完成的攻击。彩虹表只是预先生成数百万个密码的散列（这是一个时空权衡）。盐的引入使这些预先计算的哈希无效：必须为每个唯一盐制作彩虹表。
所以...
现在，如果假设攻击者拥有数据库，那么还有另一个问题：攻击速度不受限制，这就是为什么像bcrypt 或多轮这样的密码散列方案很有价值。它可以将攻击速度从每秒数亿次哈希（MD/SHA 和朋友制造变得更快）降低到每秒几百次第二个（在相同的硬件上）...还可以考虑一种 HMAC 方法，它还包含一个服务器机密（使其有效地成为密码+盐+机密）。
（我只会使用已经解决所有这些问题的现有系统，以及更多:-)
编码愉快。
【讨论】：
你列出的步骤是正确的。
如果攻击者访问您的数据库，他必须对可能的密码和随机盐进行暴力搜索。如果您使用 64 位合理随机盐，那么不会有两个条目使用相同的盐，因此任何彩虹表攻击一次只能（最多）一个盐值，这也使得彩虹表攻击贵到值得。 （您甚至可以在为用户建立盐时检查以确保没有使用给定盐的其他密码。）
加盐散列密码过程的要点是使预先计算可能的密码散列在计算上不可行，因为随机盐会破坏预计算过程。
这也意味着，如果在不同的站点使用相同的密码，则仅通过查看（加盐散列的）密码值不会很明显 - 因为不同站点的盐分会不同，因此生成的散列值会有所不同。 （当然，如果一个站点的密码被发现了，那么攻击者会先在下一个站点尝试该密码；最好还是不要在多个位置使用相同的密码。但是使用相同的密码的事实被隐藏了。）
【讨论】：
假设您没有使用盐并且攻击者获取了您的哈希值。她需要做的就是将哈希值与查找表进行比较，看看是否有任何哈希值用于已知密码。假设该表中有一百万个密码。她可以根据一百万个可能的密码非常有效地检查您的所有哈希值。
现在假设同一个攻击者得到了你的哈希值，但它们是加盐的。对于她想要检查的每个散列，她需要获取候选密码，应用盐，计算新散列，并将其与您存储的散列进行比较。现在她必须做大量的计算，而且效率不高。 （或者，她可以有一个查找表，其中包含所有可能的盐，但是好的，那么她需要一个比没有盐的查找表大几个数量级的查找表。）
这一切都是为了使破解哈希所需的资源量超过攻击者的价值。
【讨论】：