Security 在数据库中加密电子邮件地址值得吗？

我已经用它在数据库中存储密码，这意味着我应该对攻击免疫

不过，我有一个想法：如果有人真的掌握了我的数据库怎么办？它包含用户的电子邮件地址。我真的不能把它们散列，因为我会用它们来发送通知电子邮件，等等

---

我应该加密它们吗？

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

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

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

发生的可能性有多大

更换电子邮件地址所造成的损害可能比暴露电子邮件地址所造成的损害大得多。特别是如果您正在使用电子邮件地址验证密码是否重置为安全系统

---

如果对密码进行哈希运算，则密码被替换或公开的可能性会大大降低，但这取决于您使用的其他控件。

我认为这取决于数据库的应用程序

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

赞成者：

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

缺点：

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

---

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

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

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

所以我想你可以加密电子邮件，如果你想，但如果这是系统的安全程度，那么它真的做不了什么，实际上会使维护数据库的工作更加困难

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

我并不是说这是一个坏主意，但为什么要在Deadlocks'R'us的门上安装一把锁，而Deadlocks'R'us的价格是5000美元，因为他们可以穿透门周围的胶合板？还是从你开着的窗户进来？更糟糕的是，他们找到了留在门垫下的钥匙。系统的安全性只与最薄弱的环节一样好。如果他们有根访问权限，那么他们几乎可以做他们想做的事情

很好地指出，即使他们无法理解电子邮件地址，他们仍然会造成很多伤害（如果他们只有选择性访问权限，这可以减轻）

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

@Roo

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

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

我的回答：

---

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

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

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

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

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

如果您的服务器受损，则表示您无意中进行了传输。如果您担心这一点，那么您可能应该保护您的服务器。你有外部威胁，也有内部威胁。所有用户（外部和内部）是否经过适当的认证和授权

在备份过程中，您有意传输到备份介质；这是使用一种安全的备份策略来完成的，该策略会在运行时进行加密吗

我的答案的复印件在，只是为了搜索。