任何salt显然会在对用户密码进行腌制和散列处理时提供帮助。盐有多长时间有什么最佳做法吗？我将盐存储在我的用户表中，所以我希望在存储大小和安全性之间进行最佳权衡。是一个随机的10个字符的盐吗？或者我需要更长的时间吗？
答案 0 :(得分：64)
这些答案中的大多数都有点误导，并证明了盐和加密密钥之间的混淆。包含salt的目的是修改用于散列每个用户密码的函数，以便每个存储的密码散列都必须单独攻击。唯一的安全要求是每个用户都是唯一的，没有任何好处是不可预测或难以猜测。
盐只需要足够长，以便每个用户的盐都是独一无二的。即使有十亿注册用户，随机64位盐也不太可能重复，所以这应该没问题。单独重复的盐是一个相对较小的安全问题，它允许攻击者一次搜索两个帐户，但总的来说不会在整个数据库上加快搜索速度。在大多数情况下，即使是32位盐也是可以接受的，在最坏的情况下，攻击者的搜索速度将提高约58％。增加盐超过64位的成本并不高，但没有安全理由这样做。
在每个用户的盐之上使用站点范围的盐也有一些好处，这可以防止与其他站点存储的密码哈希冲突，并防止使用通用的彩虹表，尽管32位盐就足以使彩虹表成为不切实际的攻击。</ p>
更简单 - 开发人员总是忽视这一点 - 如果你有唯一的用户ID或登录名，那些服务就像盐一样完美。如果你这样做，你应该添加一个站点范围的盐，以确保你不与具有相同好主意的另一个系统的用户重叠。
答案 1 :(得分：34)
目前用于散列密码的accepted standards为每个密码创建一个新的16个字符长的盐，并使用密码散列存储盐。
当然应该采取适当的加密护理来创造真正的随机盐。
答案 2 :(得分：24)
修改：我的下面的回答回答了问题，但“真正的”答案是：只使用bcrypt，scrypt或Argon2。如果你问这样的问题，你几乎肯定会使用太低级别的工具。
老实说，没有可靠的理由不让盐与散列密码的长度相同。如果您使用的是SHA-256，那么您将拥有256位哈希值。没有理由不使用256位盐。
超过256位不会在数学上为您带来任何安全性方面的改进。但是，加入较短的盐可能总会导致彩虹表达到盐的长度 - 尤其是较短的盐。
答案 3 :(得分：7)
在Linux，BSD Unix和Linux中使用的SHA2-crypt和bcrypt方法 Solaris-具有128位的盐。这些较大的盐值会产生 几乎任何长度的密码不可行的预计算攻击 在可预见的未来对这些系统。
128位（16字节）的盐就足够了。您可以将其表示为128 / 4 = 32十六进制数字序列。
答案 4 :(得分：2)
一个答案可能是将盐的大小用作您将要使用的哈希值在安全性方面提供的值。
E.g。如果您打算使用SHA-512，则使用256位盐，因为SHA-512提供的安全性是256位。