encryption - 用户密码盐的最佳长度是多少？

Question

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

Answer 1

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

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

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

甚至更简单——开发人员总是忽略这一点——如果你有唯一的用户 ID 或登录名，它们就像盐一样完美。如果你这样做，你应该添加一个站点范围的盐，以确保你不会与另一个系统的用户重叠，他们有同样的好主意。

Answer 2

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

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

Answer 3

编辑：我下面的答案回答了所问的问题，但“真正的”答案是：只需使用bcrypt、scrypt或Argon2。如果你问这样的问题，几乎可以肯定你使用的工具级别太低了。

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

从数学上讲，超过 256 位不会为您带来任何安全性改进。但是使用较短的盐可能总是会出现彩虹表赶上您的盐长度的情况 - 特别是使用较短的盐。

Answer 4

维基百科：

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

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

Answer 5

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

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