在将密码散列存储到数据库中时，我一直使用适当的每个条目（entry）的盐字符串。对于我的需求，将盐存储在数据库中与散列密码一起工作得很好。
然而，有些人建议将盐从数据库中分开存储。他们的论点是，如果数据库被攻击者攻破，攻击者仍然可以建立彩虹表，考虑特定的盐字符串，以便逐个破解一个帐户。如果此帐户具有管理权限，则他甚至可能不需要破解其他任何帐户。
从安全的角度来看，将盐存储在不同位置是否值得呢？考虑一下服务器代码和数据库位于同一台机器上的Web应用程序。如果盐存储在该机器上的一个平面文件中，那么如果数据库被攻破，盐文件也很可能会被攻破。
有没有推荐的解决方案？
我这里提供一个略有不同的看法。
我总是将盐和经过盐加密的密码哈希值混合存储在一起。
例如，我会将盐的前半部分放在密码盐哈希之前，将盐的后半部分放在密码盐哈希之后。应用程序知道这个设计，因此可以获取这些数据，并获取盐和经过盐加密的密码哈希值。
我的做法理由：
如果密码/哈希数据被攻击者窃取，攻击者无法仅从数据中查看盐。这样，攻击者不能实际执行暴力破解攻击以获取与哈希匹配的密码，因为他不知道哈希值，也无法知道哪些部分是盐的组成部分或经过盐加密的密码哈希值的组成部分（除非他知道您的应用程序身份验证逻辑）。
如果将经过盐加密的密码哈希值存储为原样，那么可以执行暴力破解攻击以获取一个密码，该密码通过盐加密和哈希后产生与经过盐加密的密码哈希值相同的数据。
但是，例如，即使将经过盐加密的密码哈希值存储为原样，但是在前面添加了一个随机字节，只要攻击者不知道这个字节应该被丢弃，这也会增加攻击的难度。您的应用程序会知道在用于身份验证用户时丢弃数据的第一个字节。
得出结论..
1）永远不要以精确形式存储身份验证应用程序使用的数据。
2）如果可能，请保持您的身份验证逻辑保密以提高安全性。
再深入一步..
如果无法保密您的应用程序身份验证逻辑 - 许多人知道数据库中存储数据的方式。并且假设您已经决定将经过盐加密的密码哈希值与盐混合存储在一起，并且部分盐将前缀添加到经过盐加密的密码哈希之前，其余部分将后缀添加到其中。
生成随机盐时，您还可以随机决定存储盐的哈希值之前/之后的比例。
salt = "california"
passwd = "wp8tJ4Pr"
stored_passwd = salt + hash(passwd + salt)
salt = substr(stored_passwd, 0, 10)
hashed_passwd = substr(stored_passwd, 10, 40)
if hash(user_input + salt) == hashed_passwd:
print "password is verified"
盐的整个目的是防止使用预先计算的表（例如彩虹表）进行密码攻击，因此将盐与哈希密码一起存储实际上是无害的。
为什么要使用盐来防止彩虹表攻击？恶意用户以某种方式访问数据库并查看散列密码，获取最常见密码的表格，找到其哈希值并在表格中查找密码。
因此，当用户发送密码时，我们会将随机生成的盐添加到密码中。
userPassword + salt
然后我们将其传递给我们的哈希算法。
hash(userPassword+salt)
由于盐值是随机生成的，userPassword+salt 成为一个随机值，绝对不是最常用的密码之一。因此，恶意用户无法通过检查彩虹表来找出使用的密码。
现在，盐值被添加到哈希值前面，因为当用户登录时，它会再次使用，以比较传递的凭据和保存的凭据。
hash(userPassword+salt)=ashdjdaskhfjdkhfjdashadslkhfdsdh
这是密码在数据库中的存储方式：ashdjdaskhfjdkhfjdashadslkhfdsdh.salt
现在，如果恶意用户看到了这个，他可以破解密码，但需要花费巨大的时间。因为每个密码都会得到一个不同的盐值。假设恶意用户有一个包含5000个常见密码及其哈希值的表。
重要的一点是，恶意用户不只有一个表。因为有太多不同的算法，所以恶意用户将为每种算法拥有5000个密码的哈希值。
现在对于每个密码，假设他从第一个用户的密码开始，他将把那个盐值添加到5000个常见密码中，并为每个不同的算法创建一个新的彩虹表来查找仅1个密码。然后对于第二个用户的密码，他将看到一个不同的盐值，他将计算新的彩虹表。甚至不能保证用户的密码会在这些常见密码列表中。