在对用户密码进行加盐和散列时，任何加盐都显然会有所帮助。盐应该放多久有什么最佳做法吗？我将在我的用户表中存储盐，所以我希望在存储大小和安全性之间进行最佳权衡。随机10个字符的盐够吗？还是我需要更长的时间？

这些答案中的大多数都有点误导，并显示了盐和加密密钥之间的混淆。包含salts的目的是修改用于散列每个用户密码的函数，以便每个存储的密码散列都必须单独受到攻击。唯一的安全性要求是，它们是每个用户唯一的，不可预测或难以猜测对它们没有好处。

盐只需要足够长的时间，以便每个用户的盐都是独一无二的。即使有十亿注册用户，随机64位盐也不太可能重复使用，所以这应该是可以的。一个单独重复的salt是一个相对较小的安全问题，它允许攻击者同时搜索两个帐户，但总的来说不会加快整个数据库的搜索速度。即使32位的盐类在大多数情况下都是可以接受的，在最坏的情况下，它将使攻击者的搜索速度提高约58%。将盐增加到64位以上的成本并不高，但没有安全理由这样做。

在每个用户的salt上使用一个站点范围的salt也有一些好处，这将防止可能与存储在其他站点的密码哈希发生冲突，并防止使用通用彩虹表，尽管即使32位salt足以使彩虹表成为不切实际的攻击。

更简单的是，如果您有唯一的用户ID或登录名，那么开发人员总是忽略这一点，这些ID或登录名非常适合作为salt。如果你这样做了，你应该添加一个站点范围的salt，以确保你不会与另一个有相同想法的系统的用户重叠。

当前公认的散列密码标准为每个密码创建一个新的16个字符长的salt，并将salt与密码散列一起存储。

当然，应该采取适当的加密措施来创建真正的随机salt。

编辑：我下面的答案按要求回答问题，但真正的答案是：只需使用bcrypt、scrypt或argon2。如果你问这样的问题，你几乎可以肯定，你使用的工具水平太低了。

老实说，没有理由不让salt与哈希密码的长度完全相同。如果您使用的是SHA-256，那么您有一个256位散列。没有理由不使用256位的盐。

在数学上，超过256位不会使您的安全性有任何改进。但是使用较短的盐可能最终会导致一个彩虹桌赶上你的盐的长度——尤其是较短的盐。

维基百科：

The SHA2-crypt and bcrypt methods—used in Linux, BSD Unixes, and
Solaris—have salts of 128 bits. These larger salt values make
precomputation attacks for almost any length of password infeasible
against these systems for the foreseeable future.

号

128位(16字节)的盐就足够了。您可以将它表示为128 / 4 = 32十六进制数字的序列。

一个答案可能是将要使用的散列值用作salt的大小，该散列值在安全性方面提供。

例如，如果要使用sha-512，请使用256位salt，因为sha-512提供的安全性为256位。