有人可以帮我理解加盐的原理吗？
到目前为止，我了解以下内容：
我们如何存储盐，或者当用户登录时知道盐是什么？我们是否将其存储在自己的字段中？如果不这样做，应用程序如何确定盐是什么？如果我们存储它，它是否会破坏整个目标？
盐在哈希之前与密码结合在一起。密码和盐清除值被串联在一起，结果字符串被散列。这样可以保证即使两个人使用相同的密码，您也将得到不同的哈希值。 （这也使得使用彩虹表的攻击（称为字典攻击）更加困难）。
然后将盐以原始/明文格式与哈希结果一起存储。然后，当您想验证密码时，将再次执行原始过程。将记录中的盐与用户提供的密码结合在一起，对结果进行哈希处理，然后对哈希进行比较。
您可能已经知道这一点。但是要记住很重要每次必须随机生成盐。每个受保护的哈希值必须不同。通常，RNG用于生成盐。
所以..例如：用户密码：“ mypassword”随机盐：“ abcdefg12345”result-cleartext：“ mypassword：abcdefg12345”（如何组合它们取决于您，只要您每次都使用相同的组合格式）。哈希结果明文：“ somestandardlengthhashbasedonalgorithm”
现在，您将在数据库中存储所用的哈希和盐。我看过两种方式：
方法1：field1-盐=“ abcdefg12345”field2-password_hash =“ somestandardlengthhashbasedonalgorithm”
方法2：field1-password_hash =“ abcdefg12345：somestandardlengthhashbasedonalgorithm”
无论哪种情况，您都必须从数据库中加载盐和密码哈希，然后重做哈希以进行比较
salt <- random
hash <- hash(password + salt)
store hash:salt
稍后
input password
look up hash:salt
hash(password+salt)
compare with stored hash
知道了吗？
我们如何存储盐，或者当用户登录时知道盐是什么？我们是否将其存储在自己的字段中？
是
而且如果我们确实存储它，它是否会破坏整个目标？
没有盐的目的不是秘密的，而仅仅是为了防止攻击者分摊全世界所有站点（不是盐）或站点中所有用户（所有用户使用的单一盐）的彩虹表计算成本。] >
根据实用密码学
[如果您使用的是众所周知的哈希算法，那么某人可能已经拥有使用该算法已经哈希的许多可能密码的列表，并将该列表中的项目与他们想要破解的哈希密码进行比较（字典攻击）。如果您在对所有密码进行哈希处理之前先对其“加盐”，则这些字典将无用，因为必须使用盐来创建它们。