我刚刚阅读了邮件提供商的帮助页面,他们在其中声明所有手机号码都将存储为加盐哈希。这让我觉得很有趣,因为电话号码不包含很多熵:根据我的计算,大约是 31 位。
根据散列函数,生成 2 31个散列应该很快。像 bcrypt 这样的自适应哈希函数允许增加迭代次数。破解这样的哈希会花费相当长的时间,但是使用过多的哈希迭代会降低整个应用程序的速度。
长话短说:是否存在最低熵之类的东西,低于该熵,散列变得毫无意义或有害?
我刚刚阅读了邮件提供商的帮助页面,他们在其中声明所有手机号码都将存储为加盐哈希。这让我觉得很有趣,因为电话号码不包含很多熵:根据我的计算,大约是 31 位。
根据散列函数,生成 2 31个散列应该很快。像 bcrypt 这样的自适应哈希函数允许增加迭代次数。破解这样的哈希会花费相当长的时间,但是使用过多的哈希迭代会降低整个应用程序的速度。
长话短说:是否存在最低熵之类的东西,低于该熵,散列变得毫无意义或有害?
对于登录功能,您的目标应该是让散列过程花费大约一秒钟。
如果您以这篇文章为指导,1170 毫秒需要大约 8,192 次 bcrypt 迭代(成本为 13)。
这意味着您的迭代增加了大约 13 位的有效熵。
如果您在一个秘密的散列值中只有 31 位熵,那么这个 bcrypt 配置将为您提供 44 位熵。
作为指导,47 位熵最多需要 0.223 小时才能破解每个电话号码(假设每秒猜测 3500 亿次)。即使攻击者没有此类资源,并且他们使用一台家用 PC 以 20 亿次猜测/秒的速度进行猜测,每个电话号码也需要 39 小时才能破解。
因此,要回答您的问题,当您需要将散列时间增加到不可接受的水平时(添加 16 位的 16 成本将超过 9 秒,您将描述为对您的应用程序有害)是没有意义的),或者每个秘密的破解时间低于你的目标,因为它保护的信息的敏感性和你感知的攻击者的资源。
如果每个电话号码需要 39 小时才能被临时攻击者破解是可以接受的,那么 bcrypt 就没有问题,成本为 13 。这是假设他们正在使用具有上述成本的 bcrypt 而不是简单地存储 SHA1(salt + number)。
没有一条神奇的线超出了哈希是无用的。相反,随着您减少输入的熵,输出变得更容易猜测。
在这个邮件提供商的案例中,他们可以使用盐添加熵。盐越大,它增加的熵就越多。