database-design - 加密数据库密码字段的必要性

Question

我听说出于安全问题，建议在数据库中保持密码字段加密。

如果只有我的网站，我可以访问数据库。根据我们的网站政策，我查看其他密码也没有问题。

这是否也适用于我的网站，或者说这件事背后还有其他一些安全原因。

Answer 1

指导原则是，任何人（甚至用户自己）都应该能够看到密码，并且不应以允许检索密码的方式将密码存储在数据库中。这是因为这些数据可能会以多种方式丢失 - 管理员可能会打印出一份报告，然后将其留在办公桌上；攻击者可能能够使用 SQL 注入来运行数据库查询；有人可能会闯入您的建筑物并偷走备份磁带。

许多客户在多个网站上使用相同的密码 - 因此，如果您的网站是最薄弱的链接，如果他们重复使用密码，您可能会使他们在其他网站上面临风险。

建议使用一种称为“哈希”的加密技术，该技术将明文密码转换为无意义的字符串；没有办法反转散列，这意味着即使我窃取了散列密码，我也无法弄清楚原始的纯文本是什么。

对相同的字符串进行两次哈希处理会得到相同的哈希值——因此当有人登录时，您会对他们的明文密码进行哈希处理，并将其与数据库中的哈希值进行比较。

OWASP 链接提供了有关此主题的更多信息，包括“加盐”哈希。

Answer 2

您根本不应该在数据库中存储任何密码，无论是加密的还是其他的。

相反，存储一个 hash。当用户尝试登录时，计算用户输入的密码的哈希值，并将其与存储在数据库中的哈希值进行比较。

不幸的是，普通哈希很容易受到所谓的“彩虹”攻击。如果攻击者掌握了你的表，(s)他可以预先计算整个英语¹字典的哈希值，甚至是直到一定长度的所有字符组合的哈希值，生成所谓的“彩虹表”，然后快速比较它到数据库表以获取匹配的哈希值。您的一些用户一定会使用在这种攻击下可能失败的弱密码。

为防止彩虹攻击，请勿对密码本身进行哈希处理。而是哈希密码+盐。salt是一个随机的、特定于用户的字符串，不需要比散列本身更秘密²。这引入了散列的变化，因此攻击者不能再对所有用户使用相同的彩虹表。攻击者实际上必须为每个用户（和他/她的盐）生成一个新的彩虹表，希望它变得非常昂贵。

缺乏盐渍化导致了今年 LinkeIn 的大规模安全漏洞。引用纽约时报的这篇文章：

“安全专家说，加盐密码是安全 101——LinkedIn、eHarmony 和 Lastfm.com 都未能采取的基本步骤。”

当然，这应该只是多层防御的最后一层，该层旨在使攻击者在已经读取您的数据库后更加困难。你应该尽你所能从一开始就防止这种情况发生，包括防止 SQL 注入、严格的层级分离、适当的数据库安全、防火墙、定期修补等......

---

¹或其他感兴趣的人类语言。

²但理想情况下，应该单独存储，例如在定义良好的 Web 服务 API 后面。

Answer 3

您应该始终对密码进行哈希处理。用户没有理由信任您，您也无法知道您的数据库是否已被入侵。对于这样的问题，我只能假设您对网站安全有基本的了解。我们生活在索尼、美国政府、银行等公司每周都会被黑客入侵的时代。如果您认为您对此豁免，那么您应该在注册时发布它，让您的用户知道您不关心他们的隐私。

没有任何理由可以读取您的用户密码之一。

要实现密码哈希，您应该在注册期间获取密码并在存储到数据库之前对其进行哈希处理。然后当用户登录时，您应该对密码进行哈希处理，然后将哈希值与数据库中的哈希值进行比较。如果他们比较，那么它的密码相同。

另外，记得给密码加盐。这意味着如果您有一个密码“test”并对其进行哈希处理，如果另一个站点上的用户拥有密码“test”，则两个哈希值相同，他们可以根据之前的哈希值计算出密码。加盐就像在散列之前向密码添加额外数据，因此数据库中的“test”实际上可能是“test123”，每当有人输入密码时，您的 PHP 会自动将“123”附加到它。这样，在将您站点的哈希值与另一个站点进行比较时，相同密码的哈希值是不相同的。

Answer 4

你的意思是你认为你是唯一可以访问它的人。安全性应该分层实施，所以如果一个失败，后面总会有另一个。

密码应始终经过哈希处理和加盐处理。

Answer 5

我想在已经提供的好的答案上加一点。哈希算法应该很慢，否则很容易暴力破解，直到找到匹配项。一个现成的 GPU 可以计算大约 8 Giga 的组合，因此您可以在不到一毫秒的时间内尝试完整的英语词典！

这就是为什么你应该使用Bcrypt来散列你的密码，它是专门为散列密码而设计的。它具有成本因素，可以适应未来（因此更快）的硬件。