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

Question

任何 salt 显然都会在对用户密码进行加盐和散列处理时有所帮助。 是否有关于盐应该放置多长时间的最佳实践？ 我将把盐存储在我的用户表中，所以我希望在存储大小和安全性之间取得最佳权衡。 随机 10 个字符的盐够吗？或者我需要更长的时间吗？

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

从数学上讲，超过 256 位不会给您带来任何安全性改进。但是，使用较短的盐可能最终会导致彩虹表赶上您的盐长度的情况 - 尤其是使用较短的盐。

Answer 4

维基百科：

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

128 位（16 字节）盐就足够了。您可以将其表示为一系列

128 / 4 = 32

十六进制数字。

Answer 5

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

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