【发布时间】：2017-06-13 11:29:27
【问题描述】：
我已经在使用salted hashing 在我的数据库中存储密码，这意味着我应该免受rainbow table 攻击。
不过，我有一个想法：如果有人真的掌握了我的数据库怎么办？它包含用户的电子邮件地址。我不能真正散列这些，因为我将使用它们来发送通知电子邮件等。
我应该加密它们吗？
【问题讨论】：
标签： security email encryption
【发布时间】：2017-06-13 11:29:27
【问题描述】：
Bruce Schneier 对这类问题的反应很好。
密码学不是解决您的安全问题的方法。它可能是解决方案的一部分，也可能是问题的一部分。在许多情况下，密码学一开始会使问题变得更糟，而使用密码学是否是一种改进还不清楚。
本质上“以防万一”在数据库中加密您的电子邮件并不能真正使数据库更安全。数据库的密钥存储在哪里？这些密钥使用什么文件权限？数据库是否可以公开访问？为什么？这些帐户有哪些帐户限制？机器存放在哪里，谁可以物理访问这个盒子？远程登录/ssh 访问等等等等。
所以我想您可以根据需要对电子邮件进行加密，但如果这是系统安全性的范围，那么它实际上并没有起到太大作用，而且实际上会使维护数据库的工作变得更加困难。
当然，这可能是您系统的广泛安全策略的一部分 - 如果是这样，那就太好了！
我并不是说这是一个坏主意 - 但是为什么在 Deadlocks'R'us 的门上装上一把价值 5000 美元的锁，因为他们可以切开门周围的胶合板？还是从你开着的窗户进来？或者更糟糕的是，他们找到了留在门垫下的钥匙。系统的安全性与最薄弱的环节一样好。如果他们有 root 访问权限，那么他们几乎可以做他们想做的事。
Steve Morgan 提出了一个很好的观点，即使他们无法理解电子邮件地址，他们仍然可以造成很多伤害（如果他们只有 SELECT 访问权限，则可以减轻这种伤害）
了解您存储电子邮件地址的原因也很重要。我可能对this answer 有点过分了，但我的意思是你真的需要为一个帐户存储一个电子邮件地址吗？最安全的数据是不存在的数据。
【讨论】：
-
这个回复的问题在于，虽然它确实提醒人们还有其他可能的数据泄露方式，但它最终只会阻碍人们应该为这种积极思考而鼓掌。
-
@John 使用加密以防万一在我看来并不是主动思考。积极思考将评估风险并提出减轻风险的解决方案。加密可能是也可能不是该解决方案的一部分。我希望我的回答能鼓励这种想法。
-
我发现一些 WordPress 缓存插件实际上将数据库表缓存为公共 wp-content 目录中的 json 文件。这意味着 smtp 设置（如果提供用于发布帖子）和网站上的所有 cmets 都会暴露电子邮件地址。由于有人可能由于疏忽而确实看到数据库的内容但无法访问系统或数据库本身的风险，我完全支持使用存储在数据库外部的字符串来加密电子邮件地址。如果 WordPress 是这种情况，那么暴露的电子邮件地址将毫无用处。
-
如果发生数据库泄露，我相信您会希望对用户的电子邮件地址进行加密。当然，您可以说“那么您应该确保您的数据库得到很好的保护”之类的话，我要说的是，网上没有什么是无法穿透的。我总是处理最坏的情况，到目前为止，这被证明是一个非常好的做法。
-
此外，由于最近（2018 年+）的法律更新，任何能够识别欧盟公民的个人数据现在都必须根据 GDPR 法律进行散列或加密。
我意识到这是一个死胡同，但我同意 Arjan 背后的逻辑。我想指出几点：
有人可以从您的数据库中检索数据而无需检索您的源代码（即 SQL 注入、第三方数据库）。考虑到这一点，考虑使用带密钥的加密是合理的。虽然，这只是安全措施的附加措施，而不是安全措施......这是为那些想要让电子邮件比明文更私密的人准备的，
万一在更新过程中忽略了某些内容，或者攻击者设法检索了电子邮件。
IMO：如果您打算加密电子邮件，请同时存储它的加盐哈希。然后，您可以使用哈希进行验证，并省去不断使用加密查找大量数据字符串的开销。然后有一个单独的私有函数来检索和解密您的电子邮件，当您需要使用它时。
【讨论】：
与大多数安全要求一样，您需要了解威胁级别。
如果电子邮件地址被泄露会造成什么损失？
发生的可能性有多大？
如果电子邮件地址被替换，所造成的损害可能比它们被暴露时要大得多。尤其是当您使用电子邮件地址验证密码重置到安全系统时。
如果您对密码进行哈希处理，密码被替换或泄露的可能性会大大降低，但这取决于您有哪些其他控制措施。
【讨论】：
我会说这取决于您的数据库的应用程序。
最大的问题是，你将加密密钥存储在哪里？因为如果黑客除了你的数据库之外还有其他任何东西，你所有的努力可能都白费了。 （请记住，您的应用程序将需要该加密密钥来解密和加密，因此最终黑客会找到加密密钥和使用的加密方案。
专业版：
- 您的数据库泄漏仅不会暴露电子邮件地址。
缺点：
- 加密意味着性能损失。
- 如果不是不可能，分配数据库操作将更加困难。
【讨论】：
不要意外地将加密与混淆混为一谈。我们通常会混淆电子邮件以防止垃圾邮件。许多网站将使用“webmaster_at_mysite.com”来减慢爬虫将电子邮件地址解析为潜在垃圾邮件目标的速度。这应该在 HTML 模板中完成——在持久性数据库存储中这样做没有任何价值。
我们不会加密任何东西，除非我们需要在传输过程中对其保密。您的数据将在何时何地传输？
SQL 语句从客户端传输到服务器；是在同一个盒子上还是通过安全连接？
如果您的服务器遭到入侵，则您的传输是无意的。如果您对此感到担心，那么您也许应该保护您的服务器。你有外部威胁，也有内部威胁。是否所有用户（外部和内部）都经过适当的身份验证和授权？
在备份期间，您会有意地传输到备份媒体；是否使用了一种随时加密的安全备份策略？
【讨论】：
我在What is the best and safest way to store user email addresses in the database? 的答案的副本，只是为了搜索...
总的来说，我同意其他人的说法，即不值得付出努力。但是，我不同意任何可以访问您的数据库的人也可以获取您的密钥。对于 SQL 注入当然不是这样，对于以某种方式丢失或被遗忘的备份副本来说可能不是这样。而且我觉得电子邮件地址是个人信息，所以我不在乎垃圾邮件，而是在乎地址泄露后的个人后果。
当然，当您害怕 SQL 注入时，您应该确保禁止此类注入。并且备份副本应该自己加密。
不过，对于某些在线社区，成员可能绝对不希望其他人知道他们是成员（例如与心理保健、经济帮助、医疗和性建议、成人娱乐、政治等相关的内容）。在这些情况下，尽可能少地存储个人详细信息并加密那些需要的信息（请注意，数据库级加密不会阻止使用 SQL 注入显示详细信息），这可能不是一个坏主意。同样：将电子邮件地址视为个人详细信息。
对于许多网站来说，上述情况可能并非如此，您应该专注于通过 SQL 注入来禁止SELECT * FROM，并确保访问者无法通过更改 URL 以某种方式获取其他人的个人资料或订单信息。
【讨论】：
SQL Server 和 Oracle（我相信还有其他数据库）都支持数据库级别的数据加密。如果您想加密某些东西，为什么不简单地抽象对可以在数据库服务器端加密的数据的访问，让用户选择是否使用加密数据（在这种情况下，SQL 命令会有所不同）。如果用户想使用加密数据，那么它可以配置数据库服务器，所有与密钥管理相关的维护工作都是使用标准的 DBA 工具完成的，由 DB 供应商而不是你。
【讨论】：
-
这个想法是有效的，但我不确定它会如何影响性能。
对数据库中的数据进行加密是值得的，这并没有让它变得更困难，但当它以正确的方式加密时会变得更加困难，所以停止哲学并加密敏感数据;)
【讨论】：
@Roo
我有点同意你的说法，但是为了让别人更难获取数据而加密数据难道不值得吗？
根据您的推理，在您的房子里安装锁或警报器是没有用的，因为它们也很容易被破坏。
我的回复：
我想说的是，如果您有不想落入坏人之手的敏感数据，那么您可能应该尽最大努力让黑客获取它，即使它不是 100% 万无一失的.
【讨论】：
您确实必须权衡某人获得这些电子邮件地址的最坏情况、某人获得这些电子邮件地址的可能性，以及实施更改所需的额外努力/时间。
【讨论】：
我在这里错过了一个重要的答案。 当您拥有欧洲用户时，您必须遵守 GDPR 规则。 电子邮件地址被视为个人数据，这意味着Art.5 确实适用于电子邮件地址。
以确保适当安全性的方式进行处理 个人数据，包括防止未经授权或非法的保护 处理和防止意外丢失、破坏或损坏，使用 适当的技术或组织措施（“诚信和 保密”）。
当然，这并不是说您必须加密电子邮件地址。但是通过加密数据，您确实可以保护它免受窥探员工的影响。并保护自己作为开发人员免受在数据库中进行手动更改的请求。
【讨论】：