我运行的服务可以让用户登录，但是我永远不需要向他们发送电子邮件。我尝试使用户数据尽可能匿名。我对用户跟踪，销售数据等不感兴趣。我知道将有一个更简单的解决方案，例如“首先不要使用电子邮件地址”，但由于它们是GUID，因此它们是很好的登录标识符。我的服务需要经过用户验证地址的过程，这是我唯一会发送的电子邮件。
因此，我想到了匿名存储地址的想法。我最初的想法是简单地存储每个地址的SHA512哈希，但是在发生安全漏洞的情况下-我相信我的安全性可以防止-技术上有人可以使用Rainbow表来恢复至少一些地址。
要使用加盐的哈希，我需要某种方法来缩小潜在结果列表的范围，因此我不必为每个用户的每次登录都计算哈希。那不会扩展。为此，我的想法是存储电子邮件SHA512的前5个字符。当然，这并不是唯一的价值，但是它给了我更少的潜在比赛机会。从技术上讲，这一切都很好。
我担心的是，这仍然容易受到彩虹表的攻击。这五个字符足以查找可能的输入，并且攻击者已经知道，只有看起来像电子邮件地址的输入才有效。给定未加盐的哈希的第一部分和整个加盐的哈希，他们仍然有足够的能力来确定电子邮件地址。
我是否想得太多？作为记录，在这种情况下，我使用的是pgsql和php，但这实际上是实现细节。
更新：我仍然不确定是否要继续进行此操作，但是对于任何好奇的人，这里的彩虹表问题都可以轻松解决。而不是对整个电子邮件进行哈希处理并采用哈希的前几个字符，而是将电子邮件的前几个字符用作哈希输入并存储整个哈希。它可以达到相同的效果，但是彩虹表最多只能显示前几个字符。
答案 0 :(得分：0)
对我来说，我认为是。您正在俯视。 不管您的结构有多强大，总是会有很小的突破机会，因为没有人是完美的，也不可能是人为编写的脚本。 我认为您应该选择自己认为的最佳选择，然后再坚持下去。
有些事情最好留给命运。
祝你好运
答案 1 :(得分：0)
我认为您对此太想了。您说过您不需要通过电子邮件向用户发送电子邮件，因此我要回答的问题是，为什么您完全需要存储电子邮件？您提到这是一个很好的GUID，但是如果您担心数据安全性，让用户在电子邮件验证时定义用户名会不会更容易？
基本上，我描述了该电子邮件的短暂用法，该电子邮件从未存储在数据库中，仅用于发送验证电子邮件。这样一来，您就可以向电子邮件发送自定义的一次性使用链接，这将使您的用户有机会创建自定义的登录名，您可以针对数据库进行验证以确保其唯一性。
然后，您可以安全地存储此唯一标识符，而不必担心会导致电子邮件不安全。
所有这些都说，我认为没有任何必要。如您所说，电子邮件是一种出色的GUID。使它成为出色的GUID的原因在于它是如此广为人知和可用。与发布纯文本电子邮件相关的风险远低于发布纯文本密码的风险。我相信，作为开发人员的时间最好是保护私有数据，而不是公共数据。