Is it worth encrypting email addresses in the database?我已经在使用盐化哈希将密码存储在数据库中，这意味着我应该不受彩虹表攻击的影响。 不过，我有一个想法：如果有人掌握了我的数据库该怎么办？ 它包含用户的电子邮件地址。 我不能真正地散列这些，因为我将使用它们来发送通知电子邮件等。 我应该加密它们吗？ 布鲁斯·施耐尔(Bruce Schneier)对这种问题有很好的反应。
从本质上"以防万一"加密数据库中的电子邮件并不能真正使数据库更安全。数据库的密钥存储在哪里？这些密钥使用什么文件权限？数据库可以公开访问吗？为什么？这些帐户有哪些帐户限制？机器存放在哪里，谁可以实际访问此盒子？远程登录/ ssh访问等如何等等。 因此，我想您可以根据需要对电子邮件进行加密，但是，如果这是系统安全性的程度，那么它实际上并不会做很多事情，实际上会使维护数据库的工作更加困难。 当然，这可能是系统广泛的安全策略的一部分-如果是这样，那就太好了！ 我并不是说这是一个坏主意-但是，为什么Deadlocks'R'us的门上有一把锁，当他们可以切穿门周围的胶合板时，要花费5000美元？还是从您打开的窗户进来？甚至更糟的是，他们找到了留在门垫下面的钥匙。系统的安全性仅与最弱的链接一样好。如果他们具有root用户访问权限，那么他们几乎可以做他们想要的事情。 史蒂夫·摩根(Steve Morgan)指出，即使他们不了解电子邮件地址，他们仍然可以造成很大的伤害(如果他们只有SELECT访问权限，可以减轻这种伤害) 了解所有存储电子邮件地址的原因也很重要。我可能对这个答案有些不满，但是我的意思是，您真的需要存储帐户的电子邮件地址吗？最安全的数据是不存在的数据。 我意识到这是一个固定的话题，但是我同意Arjan背后的逻辑。我想指出几件事： 有人可以从数据库中检索数据而无需检索源代码(即SQL注入，第三方数据库)。考虑到这一点，考虑使用带有密钥的加密是合理的。尽管这只是安全性的一种附加衡量标准，而不是安全性……这是针对那些想要使电子邮件比纯文本更加私密的人， IMO：如果您打算对电子邮件进行加密，则还要存储它的盐化哈希。然后，您可以使用哈希进行验证，并节省经常使用加密来查找大量数据字符串的开销。然后，当您需要使用一个电子邮件时，可以使用一个单独的私有功能来检索和解密您的电子邮件。 与大多数安全要求一样，您需要了解威胁级别。 如果电子邮件地址被盗，会造成什么损失？ 它发生的机会是什么？ 如果替换电子邮件地址，则造成的损失可能比暴露后更大。例如，特别是如果您要使用电子邮件地址来验证将密码重置为安全系统。 如果对它们进行哈希处理，则可以大大减少替换或公开密码的机会，但这取决于您使用的其他控件。 我会说这取决于您数据库的应用程序。 最大的问题是，您将加密密钥存储在哪里？因为如果黑客除了您的数据库外还拥有过多资源，那么您所有的工作都可能会浪费。 (请记住，您的应用程序将需要该加密密钥来解密和加密，因此最终黑客会找到该加密密钥和使用的加密方案)。 优点：
缺点：
请勿将加密与混淆混淆。我们通常会混淆电子邮件以防止垃圾邮件。许多网站都将使用" webmaster _at_ mysite.com"来减慢爬网程序将电子邮件地址解析为潜在的垃圾邮件目标的速度。这应该在HTML模板中完成-在持久数据库存储中执行此操作没有任何价值。 除非在传输过程中需要对其保密，否则我们不会加密任何东西。您的数据何时何地传输？ SQL语句从客户端传输到服务器。是在同一盒子上还是通过安全连接？ 如果您的服务器受到威胁，则表示传输无意。如果您对此感到担心，那么也许应该保护服务器安全。您既有内部威胁，也有内部威胁。所有用户(外部和内部)是否都经过正确的身份验证和授权？ 在备份过程中，您有意传输到备份介质。这是使用安全的备份策略进行加密的吗？ SQL Server和Oracle(以及其他一些DB)也都支持数据库级别的数据加密。如果要加密某些内容，为什么不直接提取对可以在数据库服务器端加密的数据的访问权，然后让用户选择是否使用加密的数据(在这种情况下，SQL命令将有所不同)。如果用户要使用加密的数据，则可以配置数据库服务器，并且与密钥管理有关的所有维护工作都是使用标准DBA工具完成的，该工具由数据库供应商提供，而不是由您提供。 加密数据库中的数据是值得的，这并不是使它变得更困难，而是当以正确的方式对其进行加密时，它的难度就更大了，因此可以停止哲学并加密敏感数据;) 我的答案是"为了在数据库中存储用户电子邮件地址的最佳和最安全的方法是什么？"的副本。 总的来说，我同意其他人的说法，这是不值得的。但是，我不同意任何可以访问您的数据库的人都可以获取您的密钥。对于SQL Injection，这肯定不是正确的，对于丢失或遗忘的备份副本，可能并非如此。而且我认为电子邮件地址是个人详细信息，因此我不在乎垃圾邮件，而是在显示地址时的个人后果。 当然，当您担心SQL注入时，应确保禁止这种注入。并且备份副本应该自己加密。 尽管如此，对于某些在线社区，成员可能仍绝对不希望其他人知道自己是成员(例如与精神保健，财务帮助，医疗和性建议，成人娱乐，政治等有关的成员)。在那些情况下，存储尽可能少的个人详细信息并加密所需的个人详细信息(请注意，数据库级加密不会阻止使用SQL Injection显示详细信息)，这可能不是一个好主意。同样：将电子邮件地址视为个人信息。
对于许多站点而言，上述情况可能并非如此，您应集中精力通过SQL注入禁止 @Roo 我在某种程度上同意您的意思，但是仅加密数据以使某人更难获得它是否值得？ 根据您的推理，在您的房屋中放置锁或警报将毫无用处，因为它们也很容易遭到破坏。 我的回复： 我想说的是，如果您有不希望落入错误之手的敏感数据，那么即使不是100％的傻瓜证明，对于黑客来说，也应该尽可能地做到这一点。 您确实必须权衡最糟糕的情况，即有人获得了这些电子邮件地址，有人获得了这些电子邮件地址的可能性以及实施更改所需的额外工作/时间。 |
