任何salt在所有将明显有助于加盐和散列用户的密码时。盐应该有多长时间有什么最佳做法吗?我将在我的用户表中存储盐,所以我想在存储大小和安全性之间进行最佳权衡。一个随机的 10 个字符的盐就足够了吗?或者我需要更长的时间?
唯一的安全要求是每个用户都是唯一的,它们是不可预测的或难以猜测的。
盐只需要足够长，以便每个用户的盐都是唯一的。即使有十亿注册用户，随机的 64 位盐也不太可能重复，所以这应该没问题。单个重复的盐是一个相对较小的安全问题，它允许攻击者一次搜索两个帐户，但总的来说不会在整个数据库上加快搜索速度。对于大多数目的，即使是 32 位盐也是可以接受的，因此，在最坏的情况下，它将使攻击者的搜索速度提高
在每个用户的盐上使用站点范围的盐也有一些好处，这将防止与存储在其他站点的密码哈希的可能冲突，并防止使用通用的彩虹表，尽管即使 32 位盐足以使彩虹表成为不切实际的攻击。
更简单的是 — — 开发人员总是忽略这一点 — — 如果你有唯一的用户 ID 或登录名，这些作为盐是很好的。如果你这样做，你应该添加一个站点范围的盐，以确保你不会与另一个有同样聪明想法的系统的用户重叠。
目前，用于哈希密码的accepted standards为每个密码创建一个新的 16 个字符长的盐，并将盐与密码哈希一起存储。
当然，应该采取适当的加密措施来创建真正的随机盐。
Linux 、 BSD Unix 和 Solaris 中使用的 SHA2-crypt 和 bcrypt 方法具有 128 位的盐值。这些较大的盐值使得在可预见的将来，针对这些系统的几乎任何长度的密码的预计算攻击都是不可行的。
128 位（16 字节）salt 就足够了，您可以将其表示为128 / 4 = 32十六进制数字的序列。
本站系公益性非盈利分享网址，本文来自用户投稿，不代表边看边学立场，如若转载，请注明出处
评论列表（82条）