是否值得在数据库中加密电子邮件地址?

布鲁斯施耐尔对这种问题有很好的反应。

加密并不能解决您的安全问题。它可能是解决方案的一部分,也可能是问题的一部分。在许多情况下,密码学一开始就把问题弄得更糟,但目前还不清楚使用密码学是一种改进。

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

所以我想如果你愿意的话,你可以加密电子邮件,但是如果这是系统安全的范围,那么它实际上不会做太多,而且会使维护数据库的工作更加困难。

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

我并不是说这是个坏主意,但为什么要在门上安一把锁,锁是从锁上的“r'us”上拆下来的,它要花5000美元才能穿过门上的胶合板?或者从你开着的窗户进来?或者更糟的是,他们找到了门垫下的钥匙。一个系统的安全性只有最薄弱的环节那么好。如果他们有根访问权,那么他们几乎可以做他们想要的。

Steve Morgan 很好地指出,即使他们不能理解电子邮件地址,他们仍然会造成很多伤害(如果他们只有选择访问权,可以减轻伤害)

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

我知道这是一个死气沉沉的话题,但我同意Arjan背后的逻辑。我想指出几点:

有人可以从数据库中检索数据而不必检索源代码(即SQL注入、第三方数据库)。考虑到这一点,考虑使用带密钥的加密是合理的。尽管如此,这只是一种附加的安全措施,而不是安全措施……这是为那些想让电子邮件比纯文本更私密的人准备的, 在更新过程中可能会忽略某些内容,或者攻击者试图检索电子邮件。

国际海事组织: 如果你计划加密一封邮件,也要存储一个咸的散列邮件。然后您可以使用散列进行验证,并节省不断使用加密来查找大量数据字符串的开销。然后有一个单独的私人功能来检索和解密你需要使用的电子邮件。

与大多数安全需求一样,您需要了解威胁的级别。

如果电子邮件地址被破坏,会造成什么损害?

发生这种情况的可能性有多大?

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

如果散列密码,则替换或暴露密码的可能性会大大降低,但这取决于您所拥有的其他控件。

我想说这取决于你的数据库的应用。

最大的问题是,加密密钥存储在哪里?因为如果黑客超过了你的数据库,你的所有努力可能都被浪费了。(记住,您的应用程序将需要该加密密钥进行解密和加密,因此最终黑客将找到加密密钥并使用加密方案)。

赞成的意见:

• 你的数据库泄露了 只有 不会公开电子邮件地址。

欺骗:

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

不要意外地将加密与模糊混为一谈。我们通常混淆电子邮件以防止垃圾邮件。很多网站都会有“webmaster-at-mysite.com”来阻止爬虫将电子邮件地址解析为潜在的垃圾邮件目标。这应该在HTML模板中完成——在持久数据库存储中这样做没有价值。

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

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

2. 如果您的服务器被破坏,您将得到一个无意的传输。如果您担心这个问题,那么您可能应该保护您的服务器。您有外部威胁和内部威胁。所有用户(外部和内部)是否都经过了适当的认证和授权?

3. 在备份过程中,您有意传输到备份媒体;这是使用安全的备份策略来完成的吗?

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

我的答案副本 What is the best and safest way to store user email addresses in the database? 为了搜索…

总的来说,我同意其他人所说的不值得付出的努力。但是,我不同意任何可以访问您的数据库的人也可以获取您的密钥。对于SQL注入来说,这当然不是真的,对于以某种方式丢失或忘记的备份副本来说,也可能不是真的。我觉得电子邮件地址是一个个人信息,所以我不在乎垃圾邮件,而是关心地址泄露后的个人后果。

当然,当您害怕SQL注入时,应该确保禁止这种注入。备份副本应该自己加密。

尽管如此,对于一些在线社区,成员可能绝对不希望其他人知道他们是成员(例如,与心理保健、财务帮助、医疗和性咨询、成人娱乐、政治等相关)。在这些情况下,存储尽可能少的个人详细信息并对所需的信息进行加密(请注意,数据库级加密不会阻止使用SQL注入显示详细信息),这可能不是一个坏主意。再次:将电子邮件地址视为个人详细信息。

对于许多网站,上述情况可能不是这样,你应该集中精力禁止 SELECT * FROM 通过SQL注入,并确保访问者无法通过更改URL以某种方式获取其他人的个人配置文件或订单信息。

对数据库中的数据进行加密是值得的,这并不会使其变得更加困难,但当其以正确的方式加密时会变得更加困难,因此停止哲学并加密敏感数据;)

你真的需要权衡一下你最坏的情况,比如有人获得了这些电子邮件地址,有人获得这些地址的可能性,以及你实施变更所需的额外努力/时间。

@ Roo

我有点同意你所说的,但是对数据进行加密仅仅是为了让别人更难得到它,难道不值得吗?

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

我的回答是:

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