布鲁斯·施奈尔对这种问题有很好的回应。

加密技术并不能解决您的安全问题。这可能是解决方案的一部分，也可能是问题的一部分。在许多情况下，密码学一开始会使问题变得更糟，而使用密码学是否是一种改进还不清楚。

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

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

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

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

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

同样重要的是要知道你存储电子邮件地址的原因是什么。我可能对这个答案，但我的观点是，你真的需要为帐户存储电子邮件地址吗？最安全的数据是不存在的数据。

I realize this is a dead topic, but I agree with Arjan s logic behind this. There are a few things I d like to point out:

Someone can retrieve data from your database without retrieving your source code (i.e. SQL injection, third-party db s). With this in mind, it s reasonable to consider using an encryption with a key. Albeit, this is only an added measure of security, not the security...this is for someone who wants to keep the email more private than plaintext, In the off chance something is overlooked during an update, or an attacker manages to retrieve the emails.

IMO：如果你计划加密电子邮件，也要存储一个加盐的散列。然后，您可以使用哈希进行验证，并省去不断使用加密来查找大量数据字符串的开销。然后，当你需要使用一个单独的私人功能时，可以检索和解密你的电子邮件。

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

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

发生这种事的可能性有多大？

如果电子邮件地址被替换，所造成的损害可能比重新暴露更大。尤其是当您使用电子邮件地址验证密码重置到安全系统时。

如果你对密码进行散列，密码被替换或暴露的几率会大大降低，但这取决于你有什么其他控制措施。

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

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

赞成的意见：

• A leak of your DB only will not expose the e-mail addresses.

欺骗：

• Encryption means performance loss.
• Allot of database actions will be harder if not impossible.

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

除非在传输过程中需要保密，否则我们不会对任何东西进行加密。您的数据将在何时何地传输？

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

2. 如果您的服务器遭到破坏，则表示您进行了无意的传输。如果您对此感到担忧，那么您也许应该保护您的服务器。你既有外部威胁，也有内部威胁。是否所有用户（外部和内部）都经过了正确的身份验证和授权？

3. 在备份过程中，您有意传输到备份介质；这是使用一种安全的备份策略来完成的吗？

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

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

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

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

尽管如此，对于一些在线社区，成员们可能肯定不想让其他人知道他们是成员（比如与心理健康、经济帮助、医疗和性建议、成人娱乐、政治等有关）。在这些情况下，存储尽可能少的个人详细信息并对所需的信息进行加密（注意，数据库级加密不会阻止使用SQL注入显示详细信息），这可能不是一个坏主意。再次强调：将电子邮件地址视为此类个人详细信息。

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

加密数据库中的数据是值得的，这并不会让它变得更难，但当它以正确的方式加密时，它会变得更难——所以停止哲学，加密敏感数据；）

@Roo公司

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

根据你的推理，在你的房子里安装锁或警报器是没有用的，因为它们也很容易被破坏。

我的回复：

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

I miss one important answer here. When you have European users, you have to comply with the GDPR rules. Email addresses are considered personal data meaning Art.5 does apply on email addresses.

processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).

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

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