用户密码 salt 的最佳长度是多少？

小开

目前，用于哈希密码的公认的标准为每个密码创建一个新的16个字符长的 salt，并将 salt 与密码哈希一起存储。

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

小开

编辑: 我下面的答案回答了问题，但是“真正的”答案是: 只使用地下室、脚本或者 Argon2。如果你问这样的问题，你几乎肯定使用的工具在太低的水平。

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

从数学上来说，超过256位不会让你在安全性方面有任何提高。但是使用较短的盐可能最终会导致彩虹餐桌赶上你的盐长度——特别是使用较短的盐。

小开

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

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

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

甚至更简单——而且开发人员总是忽略这一点——如果您有唯一的用户 ID 或登录名，那么这些名称完全可以用作盐。如果您这样做了，您应该在整个站点范围内添加一些内容，以确保您不会与另一个系统的用户重叠，这些用户具有相同的聪明想法。

小开

维基百科:

SHA2-crypt 和 bcrypt 方法ーー用于 Linux、 BSD Unixes 和 Solaris 有128位的盐，这些较大的盐值对几乎任意长度的密码不可行的预计算攻击在可预见的将来，对这些系统。

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

小开

一个答案可能是使用您将要使用的 hash 在安全性方面提供的值作为 salt 的大小。

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