我已经在使用加盐哈希将密码存储在我的数据库中，这意味着我应该免受彩虹表攻击。
不过，我有一个想法：如果有人确实掌握了我的数据库怎么办？它包含用户的电子邮件地址。我不能真正散列这些，因为我将使用它们来发送通知电子邮件等。
我应该加密它们吗？
Roger Lipscombe
问问题
21399 次
11 回答
61
Bruce Schneier 对这类问题有很好的回应。
密码学不是解决您的安全问题的方法。它可能是解决方案的一部分，也可能是问题的一部分。在许多情况下，密码学一开始会使问题变得更糟，而使用密码学是否是一种改进还不清楚。
本质上，“以防万一”加密数据库中的电子邮件并不能真正使数据库更安全。数据库的密钥存储在哪里？这些密钥使用什么文件权限？数据库是否可以公开访问？为什么？这些帐户有哪些帐户限制？机器存放在哪里，谁可以物理访问这个盒子？远程登录/ssh 访问等呢？等等。
因此，我想您可以根据需要对电子邮件进行加密，但是如果这是系统安全性的范围，那么它实际上并没有起到太大作用，并且实际上会使维护数据库的工作变得更加困难。
当然，这可能是您系统的广泛安全策略的一部分 - 如果是这样，那就太好了！
我并不是说这是一个坏主意 - 但是为什么在 Deadlocks'R'us 的门上安装一把锁，当他们可以切开门周围的胶合板时花费 5000 美元？还是从你开着的窗户进来？或者更糟糕的是，他们找到了留在门垫下的钥匙。系统的安全性与最薄弱的环节一样好。如果他们有 root 访问权限，那么他们几乎可以做他们想做的事。
史蒂夫摩根提出了一个很好的观点，即使他们无法理解电子邮件地址，他们仍然可以造成很多伤害（如果他们只有 SELECT 访问权限，可以减轻这种伤害）
了解您存储电子邮件地址的原因也很重要。我可能对这个答案有点过分了，但我的意思是你真的需要为一个帐户存储一个电子邮件地址吗？最安全的数据是不存在的数据。
于 2008-09-16T09:00:17.790 回答
20
我意识到这是一个死胡同，但我同意 Arjan 背后的逻辑。我想指出几点：
有人可以从您的数据库中检索数据而无需检索您的源代码（即 SQL 注入、第三方数据库）。考虑到这一点，考虑使用带密钥的加密是合理的。虽然，这只是安全性的附加措施，而不是安全性……这适用于希望使电子邮件比明文更私密的人，万一
在更新过程中忽略了某些内容，或者攻击者设法检索了电子邮件。
IMO：如果您打算加密电子邮件，请同时存储它的加盐哈希。然后，您可以使用哈希进行验证，并省去不断使用加密查找大量数据字符串的开销。然后有一个单独的私人功能来检索和解密您的电子邮件，当您需要使用一个。
于 2012-08-12T16:57:33.720 回答
12
与大多数安全要求一样，您需要了解威胁级别。
如果电子邮件地址被泄露，会造成什么损害？
发生的几率有多大？
如果电子邮件地址被替换，所造成的损害可能比它们被暴露时要大得多。例如，如果您使用电子邮件地址验证密码重置到安全系统时尤其如此。
如果您对密码进行哈希处理，密码被替换或暴露的可能性会大大降低，但这取决于您拥有哪些其他控制措施。
于 2008-09-16T08:53:42.623 回答
7
我会说这取决于您的数据库的应用程序。
最大的问题是，您将加密密钥存储在哪里？因为如果黑客除了你的数据库之外还有其他任何东西，你所有的努力可能都白费了。（请记住，您的应用程序将需要该加密密钥来解密和加密，因此最终黑客会找到加密密钥并使用加密方案）。
临：
- 仅泄露您的数据库不会暴露电子邮件地址。
缺点：
- 加密意味着性能损失。
- 如果不是不可能的话，分配数据库操作将更加困难。
于 2008-09-16T08:58:10.400 回答
4
不要意外地将加密与混淆混为一谈。我们通常会混淆电子邮件以防止垃圾邮件。许多网站将使用“webmaster_at_mysite.com”来减慢爬虫将电子邮件地址解析为潜在垃圾邮件目标的速度。这应该在 HTML 模板中完成——在持久数据库存储中这样做没有任何价值。
我们不会加密任何东西，除非我们需要在传输过程中对其保密。您的数据将在何时何地传输？
SQL 语句从客户端传输到服务器；是在同一个盒子上还是通过安全连接？
如果您的服务器受到威胁，则您的传输是无意的。如果您对此感到担心，那么您也许应该保护您的服务器。你有外部威胁，也有内部威胁。是否所有用户（外部和内部）都经过适当的身份验证和授权？
在备份期间，您有意传输到备份媒体；这是使用安全备份策略完成的吗？
于 2008-09-16T10:17:18.650 回答
3
我在数据库中存储用户电子邮件地址的最佳和最安全的方法是什么？，只是为了搜索...
总的来说，我同意其他人的说法，这不值得付出努力。但是，我不同意任何可以访问您的数据库的人也可以获取您的密钥。对于 SQL 注入当然不是这样，对于以某种方式丢失或被遗忘的备份副本来说可能不是这样。而且我觉得电子邮件地址是个人信息，所以我不关心垃圾邮件，而是关心地址泄露后的个人后果。
当然，当你害怕 SQL 注入时，你应该确保这种注入是被禁止的。备份副本应自行加密。
尽管如此，对于某些在线社区，成员可能绝对不希望其他人知道他们是成员（例如与心理保健、经济帮助、医疗和性建议、成人娱乐、政治等有关的内容）。在这些情况下，尽可能少地存储个人详细信息并加密那些需要的信息（请注意，数据库级加密不会阻止使用 SQL 注入显示详细信息），这可能不是一个坏主意。再次：将电子邮件地址视为个人详细信息。
对于许多网站而言，可能并非如此，您应该专注于禁止SELECT * FROM通过 SQL 注入，并确保访问者无法通过更改 URL 以某种方式获取其他人的个人资料或订单信息。
于 2009-04-20T18:21:07.700 回答
2
SQL Server 和 Oracle（我相信还有其他数据库）都支持数据库级别的数据加密。如果您想加密某些东西，为什么不简单地抽象对可以在数据库服务器端加密的数据的访问，让用户选择是否使用加密数据（在这种情况下，SQL 命令会有所不同）。如果用户想要使用加密数据，那么它可以配置数据库服务器，并且与密钥管理相关的所有维护工作都是使用标准 DBA 工具完成的，由 DB 供应商而不是您提供。
于 2008-09-16T10:13:41.420 回答
2
对数据库中的数据进行加密是值得的，这并没有让它变得更困难，但当它以正确的方式加密时会变得更加困难，所以停止哲学并加密敏感数据；）
于 2014-09-01T19:07:11.583 回答
1
@Roo
我有点同意你的说法，但是否值得加密数据只是为了让某人更难获得它？
根据您的推理，在您的房子里安装锁或警报器是没有用的，因为它们也很容易被破坏。
我的回复：
我想说，如果您有不想落入坏人之手的敏感数据，您可能应该尽最大努力让黑客获取它，即使它不是 100% 万无一失的。
于 2008-09-16T09:08:48.237 回答
0
您确实必须权衡某人获得这些电子邮件地址的最坏情况，有人获得它们的可能性以及实施更改所需的额外努力/时间。
于 2008-09-16T08:51:58.963 回答
0
我在这里错过了一个重要的答案。当您拥有欧洲用户时，您必须遵守 GDPR 规则。电子邮件地址被视为个人数据，这意味着第5条确实适用于电子邮件地址。
以确保个人数据适当安全的方式进行处理，包括使用适当的技术或组织措施（“完整性和保密性”）防止未经授权或非法处理以及意外丢失、破坏或损坏。
当然，这并不是说您必须加密电子邮件地址。但是通过加密数据，您确实可以保护它免受窥探员工的影响。并保护自己作为开发人员免受在数据库中进行手动更改的请求。
于 2021-02-19T10:03:34.643 回答