用户密码salt的最佳长度是多少？
当腌制和散列用户密码时，任何盐都显然会有所帮助。 盐应该有多长时间才有最佳做法？ 我将把salt存储在我的用户表中，所以我希望在存储大小和安全性之间取得最佳平衡。 是一个随机的10字符盐够了吗？ 或者我需要更长的时间？
这些答案中的大部分都有点误导，并且证明盐和密码键之间存在混淆。 包含salt的目的是修改用于散列每个用户密码的函数，以便每个存储的密码散列必须单独进行攻击。 唯一的安全要求是每个用户都是唯一的，他们不可预测或难以猜测。
盐只需要足够长，以便每个用户的盐都是独一无二的。 即使有10亿注册用户，随机64位盐也不可能重复，所以这应该没问题。 单一重复的盐是一个相对较小的安全问题，它允许攻击者一次搜索两个帐户，但总体上不会加速整个数据库的搜索。 即使32位盐也可以用于大多数目的，但在最坏的情况下，攻击者的搜索速度将提高大约58％。 增加超过64位的盐的成本不高，但没有安全理由。
在每个用户盐之上使用站点范围内的盐还有一些好处，这将防止可能与存储在其他站点的密码哈希发生冲突，并防止使用通用彩虹表，尽管32位盐足以使彩虹表成为不切实际的攻击。
甚至更简单 - 开发人员总是忽视这一点 - 如果您拥有唯一的用户ID或登录名，那么这些服务器就像盐一样完美无瑕。 如果你这样做，你应该添加一个站点范围的盐，以确保你不会与另一个有着同样好点子的系统的用户重叠。
目前公认的哈希密码标准为每个密码创建一个新的16个字符长的盐，并将盐与密码哈希存储在一起。
当然应该采取正确的加密护理来创建真正的随机盐。
编辑：我的下面的答案回答了问题，但“真实”的答案是：只需使用bcrypt，scrypt或Argon2。 如果你问这样的问题，你几乎肯定会使用的工具水平太低。
坦率地说，没有可靠的理由不让盐与密码散列的长度相同。 如果你使用SHA-256，那么你有一个256位散列。 没有理由不使用256位盐。
在数学上，超过256位不会为您提供任何安全方面的改进。 但使用较短的盐可能会最终导致彩虹桌上的食盐长度增加 - 尤其是使用较短的盐。
链接地址: http://www.djcxy.com/p/21545.html