我已经使用salted hashing在我的数据库中存储密码，这意味着我应该免受rainbow table攻击。
但我有一个想法：如果有人确实掌握了我的数据库怎么办？它包含用户的电子邮件地址。我不能真正地哈希这些，因为我将使用它们发送通知电子邮件等。
我应该加密吗？
答案 0 :(得分：50)
布鲁斯施奈尔对这类问题有很好的回应。
加密技术不是解决您的安全问题的方法。它可能是解决方案的一部分，也可能是问题的一部分。在许多情况下，密码学开始时会使问题变得更糟，并且使用密码术是一种改进并不是很明显。
基本上加密数据库中的电子邮件“以防万一”并没有真正使数据库更安全。为数据库存储的密钥在哪里？这些密钥使用了哪些文件权限？数据库是否可以公开访问？为什么？这些帐户有哪些帐户限制？机器存放在哪里，谁可以物理访问此盒子？那么远程登录/ ssh访问等等等。
所以我想你可以根据需要加密电子邮件，但如果这是系统安全性的程度，那么实际上并没有做太多，实际上会使维护数据库的工作变得更难。
当然，这可能是您系统广泛安全策略的一部分 - 如果是这样那么太棒了！
我不是说这是一个坏主意 - 但是为什么要从Deadlocks'R'us锁上门，当他们可以切断门周围的胶合板时花费5000美元？或者从你打开的窗户进来？或者更糟糕的是，他们找到了留在门垫下面的钥匙。系统的安全性与最薄弱的环节一样好。如果他们有root访问权限，那么他们几乎可以做他们想要的事情。
Steve Morgan提出了一个很好的观点，即使他们无法理解电子邮件地址，他们仍然会造成很大的伤害（如果他们只有SELECT访问权限就可以减轻这种伤害）
了解存储电子邮件地址的原因也很重要。我可能对this answer有点过分了，但我的观点是你真的需要存储一个帐户的电子邮件地址吗？最安全的数据是不存在的数据。
答案 1 :(得分：10)
我意识到这是一个死的话题，但我同意Arjan背后的逻辑。我想指出一些事情：
有人可以从您的数据库中检索数据而无需检索您的源代码（即SQL注入，第三方数据库）。考虑到这一点，考虑使用密钥加密是合理的。虽然这只是一种额外的安全措施，而不是安全措施......这适用于那些希望保持电子邮件比明文更私密的人，
在更新期间，某些内容会被忽略，或者攻击者会设法检索电子邮件。
IMO：如果您打算加密电子邮件，也要存储它的盐渍哈希值。然后，您可以使用哈希进行验证，并节省不断使用加密来查找大量数据的开销。然后有一个单独的私有函数来检索和解密您的电子邮件，当您需要使用它时。
答案 2 :(得分：9)
与大多数安全要求一样，您需要了解威胁级别。
如果电子邮件地址遭到入侵，可以造成什么损害？
它发生的可能性是什么？
如果电子邮件地址被替换，那么所造成的损害可能比他们曝光时要大得多。特别是如果您正在使用电子邮件地址验证密码是否重置为安全系统。
如果您对密码进行哈希处理，密码被替换或暴露的可能性会大大降低，但这取决于您拥有的其他控件。
答案 3 :(得分：3)
我想说这取决于您的数据库的应用程序。
最大的问题是，您在哪里存储加密密钥？因为如果黑客比你的数据库多得多，你的所有努力都可能被浪费掉了。 （请记住，您的应用程序将需要该加密密钥来解密和加密，因此最终黑客将找到加密密钥并使用加密方案。）
临：
缺点：
答案 4 :(得分：3)
不要意外地将加密与混淆混淆。我们通常会混淆电子邮件以防止垃圾邮件。许多网站都会有“webmaster _at_ mysite.com”来减慢抓取工具将解析电子邮件地址作为潜在的垃圾邮件目标。这应该在HTML模板中完成 - 在持久数据库存储中执行此操作没有任何价值。
我们不加密任何东西，除非我们需要在传输过程中保密。您的数据何时何地传输？
SQL语句从客户端传输到服务器;是在同一个盒子上还是通过安全连接？
如果您的服务器遭到入侵，则会发生无意的传输。如果您对此感到担心，那么您应该保护您的服务器。您有外部威胁和内部威胁。是否对所有用户（外部和内部）进行了正确的身份验证和授权？
在备份过程中，您有意向传输到备份媒体;这是使用安全备份策略完成的，它会随着加密而加密吗？
答案 5 :(得分：2)
SQL Server和Oracle（我相信其他数据库）都支持数据库级别的数据加密。如果要加密某些内容，为什么不简单地抽象对可以在数据库服务器端加密的数据的访问，并让用户选择是否使用加密数据（在这种情况下，SQL命令将不同）。如果用户想要使用加密数据，那么它可以配置数据库服务器，并且所有与密钥管理相关的维护工作都是使用标准DBA工具完成的，该工具由数据库供应商提供，而不是由您提供。
答案 6 :(得分：1)
我在What is the best and safest way to store user email addresses in the database?的答案副本，仅仅是为了搜索......
总的来说，我同意其他人说这不值得。但是，我不同意任何可以访问您的数据库的人都可能获得您的密钥。对于SQL注入来说肯定不是这样，对于以某种方式丢失或遗忘的备份副本可能不是这样。我觉得电子邮件地址是个人的细节，所以我不关心垃圾邮件，而是关注地址泄露时的个人后果。
当然，当你害怕SQL注入时，你应该确保禁止注射。备份副本应自行加密。
但是，对于一些在线社区，成员可能绝对不希望其他人知道他们是会员（如与精神保健，经济帮助，医疗和性咨询，成人娱乐，政治等有关）。在这些情况下，尽可能少地存储个人详细信息并加密所需的信息（注意数据库级加密不会阻止细节显示使用SQL注入），可能不是一个坏主意。再次：将电子邮件地址视为个人详细信息。
对于许多网站，上述情况可能并非如此，您应该专注于通过SQL注入禁止SELECT * FROM，并确保访问者无法以某种方式通过更改URL来获取其他人的个人资料或订单信息。 / p>
答案 7 :(得分：1)
加密数据库中的数据是值得的，它不会让它变得有点困难，但是当它以正确的方式加密时更加困难，因此停止哲学并加密敏感数据;）
答案 8 :(得分：0)
你真的必须权衡获得这些电子邮件地址的人的最坏情况，有人获得这些地址的可能性，以及你所需要的额外努力/时间。
答案 9 :(得分：0)
@Roo
我有点同意你所说的但不值得加密数据只是为了让某人更难获得它吗？
根据你的推理，你家里有锁或闹钟是没用的，因为它们也很容易受到损害。
我的回复：
我会说，如果你有敏感的数据，你不想落入坏人手中，你应该尽可能地让黑客得到它，即使它不是100％的傻瓜证明
答案 10 :(得分：0)
我在这里错过了一个重要的答案。 当您有欧洲用户时，您必须遵守 GDPR 规则。 电子邮件地址被视为个人数据，这意味着 Art.5 确实适用于电子邮件地址。
<块引用>以确保适当安全的方式处理 个人数据，包括防止未经授权或非法的 处理和防止意外丢失、破坏或损坏，使用 适当的技术或组织措施（“诚信和 保密’）。
当然，这并不是说您必须加密电子邮件地址。但是通过加密数据，您确实可以保护它免受员工的窥探。并保护自己作为开发人员免受在数据库中进行手动更改的请求。