我已经在使用盐化哈希将密码存储在数据库中，这意味着我应该不受彩虹表攻击的影响。

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

我应该加密它们吗？

解决方案

回答

我们确实必须权衡最糟糕的情况，即有人获得了这些电子邮件地址，有人获得了这些电子邮件地址的可能性以及实施更改所需的额外工作/时间。

回答

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

如果电子邮件地址被盗，会造成什么损失？

它发生的机会是什么？

如果更换电子邮件地址，则造成的损失可能比暴露于电子邮件地址时造成的损失要大得多。例如，特别是如果我们要使用电子邮件地址来验证将密码重置为安全系统。

如果对它们进行哈希处理，则可以大大减少替换或者公开密码的机会，但这取决于我们使用的其他控件。

回答

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

最大的问题是，我们将加密密钥存储在哪里？因为如果黑客除了DB之外还拥有多余的资源，那么我们所有的工作都可能被浪费了。 (请记住，应用程序将需要该加密密钥来解密和加密，因此最终黑客会找到该加密密钥和使用的加密方案)。

优点：

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

缺点：

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

回答

布鲁斯·施耐尔(Bruce Schneier)对这种问题有很好的反应。

Cryptography is not the solution to your security problems. It might be part of the solution, or it might be part of the problem. In many situations, cryptography starts out by making the problem worse, and it isn't at all clear that using cryptography is an improvement.

本质上"以防万一"加密数据库中的电子邮件并不能真正使数据库更安全。数据库的密钥存储在哪里？这些密钥使用什么文件权限？数据库可以公开访问吗？为什么？这些帐户有哪些帐户限制？机器存放在哪里，谁可以实际访问此盒子？远程登录/ ssh访问等如何等等。

因此，我想我们可以根据需要对电子邮件进行加密，但是，如果这是系统安全性的程度，那么它实际上并没有做很多事情，实际上会使维护数据库的工作更加困难。

当然，如果这样的话，这可能是系统广泛的安全策略的一部分！

我并不是说这是个坏主意，但是为什么Deadlocks'R'us的门上有一把锁，当他们可以切穿门周围的胶合板时，要花掉5000美元？还是从我们打开的窗户进来？甚至更糟的是，他们找到了留在门垫下面的钥匙。系统的安全性仅与最薄弱的环节一样好。如果他们具有root用户访问权限，那么他们几乎可以做他们想做的事情。

史蒂夫·摩根(Steve Morgan)指出，即使他们无法理解电子邮件地址，他们仍然可以造成很大的伤害(如果他们只有SELECT访问权限，可以减轻这种伤害)

了解我们存储原因的原因也很重要。我可能对这个答案有些不满，但是我的意思是，我们真的需要存储帐户的电子邮件地址吗？最安全的数据是不存在的数据。

回答

Ro

我在某种程度上同意意思，但是仅加密数据以使某人更难获得它就值得吗？

根据推理，在房屋中放置锁或者警报将毫无用处，因为它们也很容易遭到破坏。

我的回复：

我想说的是，如果我们有不想落入错误之手的敏感数据，那么即使不是100％的傻瓜证明，我们也应该尽最大努力使黑客获取它。

回答

SQL Server和Oracle(我相信还有其他DB)都支持数据库级别的数据加密。如果要加密某些内容，为什么不直接提取对可以在数据库服务器端加密的数据的访问权，然后让用户选择是否使用加密的数据(在这种情况下，SQL命令将有所不同)。如果用户要使用加密的数据，则可以配置数据库服务器，并且所有与密钥管理有关的维护工作都是使用标准DBA工具完成的，该工具由数据库供应商提供，而不是由我们提供。

回答

请勿将加密与混淆混淆。我们通常会混淆电子邮件以防止垃圾邮件。许多网站都将使用" webmaster atmysite.com"来减慢抓取程序将电子邮件地址解析为潜在垃圾邮件目标的速度。这应该在HTML模板中完成-在持久数据库存储中执行此操作没有任何价值。

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

• SQL语句从客户端传输到服务器；是在同一盒子上还是通过安全连接？
• 如果服务器受到威胁，则表示传输无意。如果我们对此感到担心，那么我们可能应该保护服务器安全。我们既有外部威胁，也有内部威胁。所有用户(外部和内部)是否都经过正确的身份验证和授权？
• 在备份过程中，我们有意传输到备份介质。使用安全的加密备份策略来完成此操作吗？

回答

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

总的来说，我同意其他人的说法，这是不值得的。但是，我不同意任何可以访问数据库的人都可以获取密钥。对于SQL Injection，这肯定不是正确的，对于丢失或者遗忘的备份副本，可能并非如此。而且我认为电子邮件地址是个人详细信息，因此我不会在乎垃圾邮件，而是在透露地址时的个人后果。

当然，当我们担心SQL注入时，应确保禁止这种注入。并且备份副本应该自己加密。

但是，对于某些在线社区，成员可能仍绝对不希望其他人知道自己是成员(例如与精神保健，财务帮助，医疗和性建议，成人娱乐，政治等有关的成员)。在这些情况下，存储尽可能少的个人详细信息并加密所需的个人详细信息(请注意，数据库级加密不会阻止使用SQL Injection显示详细信息)，这并不是一个坏主意。再次：将电子邮件地址视为个人信息。

对于许多站点而言，上述情况可能并非如此，我们应集中精力通过SQL注入禁止" SELECT * FROM"，并确保访问者无法以某种方式通过更改URL来获取他人的个人资料或者订单信息。