我们想存储一个人的数据而不存储他们的电子邮件地址,但我们希望稍后在他们提供他们的电子邮件地址时将该人与他们的数据联系起来。
存储他们(小写的)电子邮件地址的 SHA1 可以实现这一点,但是两个不同的电子邮件地址是否有可能产生相同的 SHA1?如果有,概率是多少?
赛尔
我们想存储一个人的数据而不存储他们的电子邮件地址,但我们希望稍后在他们提供他们的电子邮件地址时将该人与他们的数据联系起来。
存储他们(小写的)电子邮件地址的 SHA1 可以实现这一点,但是两个不同的电子邮件地址是否有可能产生相同的 SHA1?如果有,概率是多少?
赛尔
这种意外发生的可能性微乎其微。当您有电子邮件地址时,大约是 n 2 /2 159 。n例如,如果您有 10 亿封电子邮件,则机会是 2 -99或 10 -30。
因此,假设它不会偶然发生是一个非常安全的赌注。
有人将能够制作具有相同哈希的两个电子邮件地址,但他将无法制作与另一个人的电子邮件不完全相同的哈希匹配的电子邮件。
或者正如密码学家所说,针对 SHA-1 的碰撞攻击是可行的,但前映像不是。
但是碰撞攻击似乎与您的应用程序无关。因为我看不到攻击者如何利用拥有两封具有匹配哈希的电子邮件。
猜测电子邮件并根据哈希确认它是可能的。这里的主要问题是 SHA-1 速度很快。
我对MD5 gravatar hashes stackoverflow publishes进行了这样的攻击,并恢复了大约 28%。付出更多努力的人可能会恢复得更多。
我的建议是使用昂贵的散列结构,例如 PBKDF-2-HMAC-SHA-2 和每个应用程序的盐。
如果您采用n 个地址,则发生冲突的概率(两个不同的地址散列到相同的值)接近n 2 *2 -159(对于n的实际值)。在实践中,你完全可以忽略碰撞的风险(你被狂犬咬死的风险要高得多)。
请注意:
SHA-1 有一些加密弱点,这使得不怀好意的人更容易故意创建两个不同的电子邮件地址,这些地址将哈希为相同的值。这仍然是一个理论上的弱点,因为虽然所描述的方法比2 80的理论成本更快,但它仍然需要大量的2 61哈希函数评估。此外,可能很难将计算出的冲突改造成电子邮件地址的格式。无论如何,您可能会更加谨慎地使用 SHA-256 而不是 SHA-1(如果您经过审核,它看起来会更好)。
电子邮件地址可以不区分大小写。特别是,根据法规,域名(在“@”之后)不区分大小写,因此example.com和Example.COM都是exAmPLE.cOM等价的。对于出现在“@”符号之前的内容,这取决于站点。您可能希望在散列之前进行一些规范化,并且可能没有适用于所有现有电子邮件地址的好的解决方案。
编辑:尽管这回答了您的确切问题,但建议您查看@CodeInChaos 的答案,该答案试图进一步了解您的问题:是否可以提供电子邮件地址并验证它是否与存储的哈希匹配,然后它可以根据哈希值“尝试”潜在的电子邮件地址,并且它往往会起作用。这是字典攻击的一种变体,它可能是也可能不是您的安全模型的大问题。
这个术语是(SHA1)碰撞,互联网上有很多关于它的资源。
电子邮件地址的数量和生日问题会增加发生冲突的机会,但对于这种实际用途,您可能永远不会发生冲突。
您应该期待不同的问题,例如带有点的电子邮件地址。Gmail 将忽略电子邮件地址中的任何点,因此first.name.lastname@gmail.com与 相同,firstnamelastname@gmail.com但哈希值会有所不同。