安全地散列密码 - 这么多相互矛盾的建议！

Question

我正在阅读很多关于如何安全存储密码的相互矛盾的建议。我所知道的肯定是不要使用 MD5！我见过有人提倡使用 PHP 的 bcrypt 函数，这似乎会占用服务器的处理器。我见过提倡盐的人，也见过不使用盐的人。

这一切都太不清楚了。是否有关于如何安全存储密码的真实可信的建议？

编辑：经过大量研究，我发现了一篇来自 ;login: 的文章，该文章相当深入地处理了该主题：http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf

Answer 1

这类似于这个问题：Methods for storing login information in database

可靠的建议：切勿以明文形式存储您的密码！

除此之外，您还有一些选择。正如我在对链接问题的回复中提到的，有两个阵营：让其他人存储您的身份验证数据或自己做。如果你决定自己做，那么你需要想出一个散列例程。这可能应该包括对您的密码进行加盐。

Answer 2

首先你需要使用一个好的散列函数，我建议使用 SHA-256。您可以像这样创建 SHA-256 哈希：

$hash = hash('sha256', $password);

此外，您还可以像这样使用盐渍：

$salt = 'salt here';
$hash = hash('sha256', $salt . $password);

此外，您可以像这样使用 HMAC：

$secret = 'your secret';
$hmac = hash_hmac('sha256', $password, $secret);

创建可靠哈希的最佳方法是通过加盐和迭代。 您应该循环上述函数，直到散列需要 200 毫秒。

您也可以继续使用加密，但在大多数情况下这有点矫枉过正。

Answer 3

嗯，这有几个部分。

1. 首先，您需要设法让访问您的数据库和密码变得困难，并确保它们的安全。这包括不使您的密码明文并且不使用对称加密算法。
2. 您需要使用salt。这样做可以防止人们使用预先计算的查找表（即彩虹表）或类似http://md5.rednoize.com/ 的东西。为您的盐选择一些独特和不可预测的数据。我通常使用随机的 32 位值，但我不会少用。
3. 某些算法比其他算法更强大。这是通过几种方式定义的
   1. 计算速度有多快。越长越好。攻击者计算哈希的速度越快，暴力攻击的可能性就越大。
   2. 如果算法没有已知的弱点会减少搜索空间。例如，md5 哈希中的位数具有误导性，因为有known attacks 会减少实际搜索空间

截至今天，我认为 SHA1 or SHA2 加盐在不久的将来是相当安全的。有一个名为 bcrypt 的实用程序使用了河豚的不对称变体，并内置了盐和计算费用的概念，可能值得一试。

---

编辑：我想澄清一下什么是盐，因为在 SO 和网上存在很多对它的误解。

什么是盐不是

一个秘密，预先商定的字符串，你用密码散列。这是密钥，不是盐。

什么是盐

您在散列时将盐（每个散列唯一且不可预测）与您的密码一起包含，但您还包含它的未加密副本在散列之外，所以在稍后验证哈希时，您可以在对哈希之前给出测试密码时包含相同的盐，这样您就可以正确比较哈希。

Answer 4

您可以使用 sha256。一个好的做法是在密码中添加额外的信息，例如用户名、用户 ID 或其他一些数据。这样，如果有人破解了你的数据库，就不可能使用现有的哈希数据库来找到密码。他们将不得不从零开始破解密码。

Answer 5

bycrpt 的意义在于 占用处理器！ （相对而言。）正是由于这个原因，密码散列比 SHA1/2 “更好”。 （这个“更好”假设密码哈希已经在攻击者手中或以其他方式暴露；虽然如果不是这样就好了，即使是大公司也有安全隐患。）

bcrypt 明确考虑了此要求——如果您每秒只能处理 1k 哈希（不过，这是一个很好的登录尝试），这需要多长时间攻击者暴力破解？比他们每秒处理 1000 万个哈希值要长得多！暴力破解的目标攻击空间仅是允许的密码输入，通常要小得多——尤其是。在实践中使用“简单密码”——而不是散列空间！

并且非常需要盐来避免以时间换空间的彩虹表 :) 实际上需要为每个独特的盐值创建彩虹表。（因此，更独特的盐值，需要更多的空间，如果值足够，这对于攻击者来说变得不切实际。）

编码愉快。