是否值得对数据库中的电子邮件地址进行加密？

你真的必须权衡你最坏的情况，即有人获得这些电子邮件地址，有人获得它们的可能性，以及你为实现改变而需要的额外努力/时间。

与大多数安全要求一样，您需要了解威胁级别。

如果电子邮件地址被泄露，会造成什么损害？

它发生的可能性有多大？

如果电子邮件地址被替换，则造成的损害可能比暴露时大得多。例如，当您使用电子邮件地址验证密码重置为安全系统时。

如果您对密码进行哈希处理，则密码被替换或暴露的可能性会大大降低，但这取决于您拥有哪些其他控件。

我想说这取决于您的数据库的应用。

最大的问题是，加密密钥存储在哪里？因为如果黑客的数据库比你的数据库多，你所有的努力都可能白费了。（请记住，您的应用程序将需要该加密密钥来解密和加密，因此黑客最终会找到加密密钥和使用的加密方案）。

优点：

• 仅数据库泄漏不会暴露电子邮件地址。

缺点：

• 加密意味着性能损失。
• 如果不是不可能的话，数据库操作的分配将更加困难。

布鲁斯·施奈尔（Bruce Schneier）对这类问题有很好的回应。

加密不是解决安全问题的方法。它可能是解决方案的一部分，也可能是问题的一部分。在许多情况下，密码学一开始就使问题变得更糟，并且完全不清楚使用密码学是否是一种改进。

从本质上讲，在数据库中加密您的电子邮件“以防万一”并不能真正使数据库更安全。数据库的密钥存储在哪里？这些密钥使用哪些文件权限？数据库是否可公开访问？为什么？这些账户有哪些账户限制？机器存放在哪里，谁可以物理访问这个盒子？远程登录/ssh访问等怎么样等等等等。

所以我想如果你愿意，你可以加密电子邮件，但如果这是系统的安全程度，那么它真的没有做太多事情，实际上会使维护数据库的工作更加困难。

当然，这可能是您系统广泛安全策略的一部分 - 如果是这样，那就太好了！

我并不是说这是一个坏主意 - 但是为什么 Deadlocks'R'us 的门上有一把锁，当他们可以切开门周围的胶合板时，它要花 5000 美元？还是从你敞开的窗户进来？或者更糟糕的是，他们找到了留在门垫下的钥匙。系统的安全性取决于最薄弱的环节。如果他们有root访问权限，那么他们几乎可以做他们想做的事。

史蒂夫·摩根（Steve Morgan）提出了一个很好的观点，即使他们无法理解电子邮件地址，他们仍然可以造成很大的伤害（如果他们只有SELECT访问权限，则可以减轻这种伤害）

了解存储电子邮件地址的原因也很重要。我的这个答案可能有点过火了，但我的观点是，你真的需要为一个帐户存储一个电子邮件地址吗？最安全的数据是不存在的数据。

@Roo

我有点同意你说的，但难道不值得加密数据只是为了让某人更难获得它吗？

根据你的推理，在你家里安装锁或警报器是没有用的，因为它们也很容易受到损害。

我的回答：

我想说的是，如果你有敏感数据，你不想落入坏人之手，你可能应该尽你所能让黑客获取它，即使它不是100%万无一失的。

SQL Server 和 Oracle（我相信还有其他数据库）都支持数据库级别的数据加密。如果要加密某些内容，为什么不简单地抽象出对数据的访问，这些数据可以在数据库服务器端加密，并让用户选择是否使用加密数据（在本例中，SQL 命令会有所不同）。如果用户想要使用加密数据，那么它可以配置数据库服务器，并且所有与密钥管理相关的维护工作都是使用标准 DBA 工具进行的，该工具由数据库供应商而不是您完成。

不要意外地将加密与混淆混淆。我们通常会对电子邮件进行混淆处理，以防止垃圾邮件。许多网站都会有“网站管理员 _at_ mysite.com”，以减缓爬虫将电子邮件地址解析为潜在垃圾邮件目标的速度。这应该在 HTML 模板中完成 -- 在持久性数据库存储中这样做没有任何价值。

我们不会加密任何内容，除非我们需要在传输过程中保密。您的数据将在何时何地传输？

1. SQL 语句从客户端传输到服务器;是在同一个盒子上还是通过安全连接？

2. 如果您的服务器遭到入侵，则您有意外传输。如果您担心这一点，那么您也许应该保护您的服务器。你有外部威胁和内部威胁。所有用户（外部和内部）是否都经过适当的身份验证和授权？

3. 在备份期间，您有意传输到备份介质;这是否使用随时加密的安全备份策略来完成？

我的答案的副本 在数据库中存储用户电子邮件地址的最佳和最安全的方法是什么？，只是为了搜索......

---

总的来说，我同意其他人的说法，这不值得付出努力。但是，我不同意任何可以访问您的数据库的人也可以获得您的密钥。对于SQL注入来说，这当然不是真的，对于以某种方式丢失或遗忘的备份副本来说，可能也不是这样。而且我觉得电子邮件地址是个人详细信息，所以我不会关心垃圾邮件，而是关心地址被泄露时的个人后果。

当然，当你害怕SQL注入时，你应该确保这种注入是被禁止的。备份副本本身应加密。

尽管如此，对于一些在线社区来说，成员可能绝对不希望其他人知道他们是成员（例如与精神保健、经济帮助、医疗和性建议、成人娱乐、政治等有关）。在这些情况下，尽可能少地存储个人详细信息并加密所需的详细信息（请注意，数据库级加密不会阻止使用 SQL 注入显示详细信息），可能不是一个坏主意。再说一遍：将电子邮件地址视为此类个人详细信息。

对于许多网站来说，上述情况可能并非如此，您应该专注于通过 SQL 注入进行禁止，并确保访问者无法通过更改 URL 以某种方式访问其他人的个人资料或订单信息。SELECT * FROM

我意识到这是一个死话题，但我同意 Arjan 背后的逻辑。我想指出几件事：

有人可以从您的数据库中检索数据而无需检索您的源代码（即 .SQL 注入、第三方数据库）。考虑到这一点，考虑使用密钥加密是合理的。虽然，这只是一种额外的安全措施，而不是安全性......这适用于希望使电子邮件比纯文本更私密的人， 以防在更新过程中忽略某些内容，或者攻击者设法检索电子邮件。

国际 海事 组织：如果您打算加密电子邮件，请同时存储它的加盐哈希值。然后，您可以使用哈希值进行验证，并省去不断使用加密来查找大量数据串的开销。然后有一个单独的私人功能，在您需要使用时检索和解密您的电子邮件。

在数据库中加密数据是值得的，它不会让它变得更困难，而是在以正确的方式加密时变得更加困难，所以停止哲学并加密敏感数据;)

我在这里错过了一个重要的答案。 当您拥有欧洲用户时，您必须遵守 GDPR 规则。 电子邮件地址被视为个人数据，这意味着第 5 条确实适用于电子邮件地址。

以确保适当安全性的方式进行处理 个人数据，包括防止未经授权或非法的保护 处理和防止意外丢失、破坏或损坏，使用 适当的技术或组织措施（'诚信和 保密性'）。

当然，这并不是说您必须加密电子邮件地址。但是，通过加密数据，您可以保护数据免受员工的窥探。并保护自己作为开发人员免受在数据库中进行手动更改的请求。