我已经在使用了 加盐哈希 将密码存储在我的数据库中,这意味着我应该免受 彩虹桌 攻击。

不过我有一个想法:如果有人掌握了我的数据库怎么办?它包含用户的电子邮件地址。我无法真正对这些进行哈希处理,因为我将使用它们来发送通知电子邮件等。

我应该加密它们吗?

有帮助吗?

解决方案

布鲁斯·施奈尔对这类问题有很好的应对。

密码学并不能解决您的安全问题。它可能是解决方案的一部分,也可能是问题的一部分。在许多情况下,密码学一开始会让问题变得更糟,而且使用密码学是否是一种改进根本不清楚。

从本质上讲,“以防万一”对数据库中的电子邮件进行加密并不能真正使数据库更安全。数据库的密钥存储在哪里?这些密钥使用哪些文件权限?数据库可以公开访问吗?为什么?这些帐户有哪些帐户限制?机器存放在哪里,谁可以物理访问这个盒子?远程登录/ssh 访问等怎么样?ETC。ETC。

因此,我想您可以根据需要对电子邮件进行加密,但如果这是系统安全的程度,那么它实际上并没有多大作用,而且实际上会使维护数据库的工作变得更加困难。

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

我并不是说这是一个坏主意 - 但为什么要在 Deadlocks'R'us 的门上安装一把价值 5000 美元的锁,因为他们可以切开门周围的胶合板呢?或者从你打开的窗户进来?或者更糟糕的是,他们发现了留在门垫下的钥匙。系统的安全性取决于最薄弱的环节。如果他们拥有 root 访问权限,那么他们几乎可以做他们想做的事。

史蒂夫·摩根 很好的一点是,即使他们无法理解电子邮件地址,他们仍然可以造成很多伤害(如果他们只有 SELECT 访问权限,则可以减轻这种伤害)

了解存储电子邮件地址的原因也很重要。我可能有点过头了 这个答案, ,但我的观点是,您真的需要存储帐户的电子邮件地址吗?最安全的数据是不存在的数据。

其他提示

我意识到这是一个死话题,但我同意 Arjan 背后的逻辑。有几点我想指出:

有人可以从您的数据库中检索数据,而无需检索您的源代码(即SQL 注入、第三方数据库)。考虑到这一点,考虑使用带有密钥的加密是合理的。尽管如此,这只是一种额外的安全措施,而不是安全性......这适用于那些想要使电子邮件比纯文本更加私密的人, 万一更新过程中忽略了某些内容,或者攻击者设法检索了电子邮件。

国际海事组织: 如果您计划加密电子邮件,请同时存储它的加盐哈希值。然后,您可以使用哈希值进行验证,从而节省不断使用加密来查找大量数据的开销。然后,当您需要使用电子邮件时,可以使用单独的私人功能来检索和解密您的电子邮件。

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

如果电子邮件地址被泄露会造成什么损害?

发生的几率有多大?

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

如果对密码进行哈希处理,密码被替换或暴露的可能性会大大降低,但这取决于您采取的其他控制措施。

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

最大的问题是,加密密钥存储在哪里?因为如果黑客拥有超出您的数据库的任何东西,那么您的所有努力可能都会被浪费。(请记住,您的应用程序将需要该加密密钥来解密和加密,因此黑客最终会找到加密密钥并使用加密方案)。

专业人士:

  • 您的数据库泄漏 仅有的 不会暴露电子邮件地址。

缺点:

  • 加密意味着性能损失。
  • 数据库操作的分配即使不是不可能,也会变得更加困难。

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

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

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

  2. 如果您的服务器受到威胁,则会发生意外传输。如果您担心这一点,那么您也许应该保护您的服务器。您面临外部威胁和内部威胁。所有用户(外部和内部)是否都经过正确的身份验证和授权?

  3. 在备份期间,您有意识地传输到备份介质;这是使用实时加密的安全备份策略完成的吗?

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

我的答案的副本位于 在数据库中存储用户电子邮件地址的最佳和最安全的方法是什么?, ,只是为了搜索......


总的来说,我同意其他人的说法,这不值得付出努力。但是,我不同意任何可以访问您的数据库的人也可能可以获得您的密钥。对于 SQL 注入来说肯定不是这样,对于以某种方式丢失或忘记的备份副本来说也可能不是这样。我认为电子邮件地址是个人详细信息,因此我不会关心垃圾邮件,而是关心地址泄露时的个人后果。

当然,当您害怕 SQL 注入时,您应该确保禁止此类注入。并且备份副本应该自行加密。

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

对于许多网站来说,上述情况可能并非如此,您应该重点关注禁止 SELECT * FROM 通过 SQL 注入,并确保访问者无法通过更改 URL 来获取其他人的个人资料或订单信息。

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

您确实必须权衡某人获取这些电子邮件地址的最坏情况、某人获取这些电子邮件地址的可能性,以及实施更改所需的额外努力/时间。

@Roo

我有点同意你的说法,但是仅仅为了让别人更难获取数据而加密数据难道不值得吗?

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

我的回复:

我想说的是,如果您拥有不想落入坏人手中的敏感数据,那么您可能应该尽最大努力让黑客获取它,即使它不是 100% 万无一失。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top