用户密码盐的最佳长度是多少？[关闭]

盐分和哈希用户密码时，任何盐分都显然会有所帮助。是否有关于盐应保留多长时间的最佳实践？我将盐存储在用户表中，因此我希望在存储大小和安全性之间取得最佳平衡。随机添加10个字符的盐是否足够？还是我需要更长的时间？

这些答案大多数都被误导了，表明了盐和加密密钥之间的混淆。包含盐的目的是修改用于对每个用户的密码进行哈希处理的功能，以便每个存储的密码哈希将必须分别受到攻击。唯一的安全性要求是它们对于每个用户都是唯一的，因此无法预测或难以猜测没有任何好处。

盐只需要足够长，以便每个用户的盐都是唯一的。即使拥有十亿注册用户，随机64位盐也极不可能重复出现，因此应该没问题。一次重复执行盐操作就不会造成太大的安全问题，它使攻击者可以一次搜索两个帐户，但总的来说并不会大大加快整个数据库的搜索速度。对于大多数目的，即使32位盐也可以接受，在最坏的情况下，它将使攻击者的搜索速度提高约58％。将盐增加到64位以上的代价并不高，但是没有安全理由这样做。

在每个用户的盐之上还使用站点范围的盐有一些好处，这将防止与存储在其他站点的密码哈希可能发生冲突，并防止使用通用彩虹表，即使32位的盐足以使彩虹桌子变得不切实际。

如果您有唯一的用户ID或登录名，那么即使是简单的开发人员也总是会忽略这一点，如果您使用的是唯一的用户ID或登录名，那么它们就很好用了。如果这样做，则应在整个站点范围内添加盐，以确保不会与具有相同主意的另一个系统的用户重叠。

当前接受的哈希密码标准为每个密码创建了一个新的16字符长的盐，并将盐与密码哈希一起存储。

当然，应该采取适当的加密措施以产生真正随机的盐。

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

老实说，没有合理的理由不让盐与哈希密码具有相同的长度。如果您使用的是SHA-256，则您有256位的哈希值。没有理由不使用256位盐。

从数学上讲，超过256位不会使您在安全性方面有任何改善。但是，使用较短的盐总是可能会遇到彩虹表赶上您的盐长度的情况，尤其是较短的盐时。

维基百科：

在Linux，BSD Unix和Solaris中使用的SHA2-crypt和bcrypt方法具有128位的盐。这些较大的盐值使得在可预见的将来，针对这些系统的几乎所有长度的密码都无法进行预计算攻击。

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

一个答案可能是将要使用的哈希值在安全性方面提供的值用作盐的大小。

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