将密码本身用作盐是个好主意吗答案

【问题标题】：Is it an good idea of Using password itself as an salt将密码本身用作盐是个好主意吗
【发布时间】：2014-06-25 18:29:18
【问题描述】：

我读过很多文章，我们应该在散列之前为每个密码组合一个唯一的盐并将盐存储在数据库中以进行验证，但是使用密码本身作为盐怎么样？

这样做会有好处，因为盐对每个人来说都是独一无二的，而且它会被隐藏起来，因为它不会存储在任何地方。

上面我可以举一个简单的例子：

$hashToStore=sha1(strrev($password).$password);

上面我只是反转密码并将其用作盐（我将做一些更复杂的事情，然后只是在开发中反转它。）

这是存储密码的更好方法还是不好的做法。

PS：我完全了解 php 最新的内置函数，例如 crypt() 并在现实世界中使用它，但还想对上述内容进行评论。

【问题讨论】：

如果两个人有相同的密码，那么那个盐现在就不是唯一的了吧？
不，这很糟糕。不要这样做。盐应该是随机的。同样sha1 对密码散列也很糟糕。
判断就用：php.net/manual/en/function.password-hash.php
@Dismissile s/encrypted/hashed
为了图灵的爱，请使用PASSWORD_HASH！！

标签： php password-storage

【解决方案1】：

一个常见的错误是在每个哈希中使用相同的盐。盐要么被硬编码到程序中，要么随机生成一次。这是无效的，因为如果两个用户有相同的密码，他们仍然有相同的哈希值。攻击者仍然可以使用反向查找表攻击同时对每个散列进行字典攻击。他们只需要在对密码进行散列之前将盐应用于每个密码猜测。如果盐被硬编码到流行产品中，则可以为该盐构建查找表和彩虹表，以便更容易破解产品生成的哈希。

每次用户创建帐户或更改密码时，都必须生成一个新的随机盐。

[…] 很容易得意忘形，尝试组合不同的哈希函数，希望结果更安全。但是，在实践中，这样做几乎没有什么好处。它所做的只是造成互操作性问题，有时甚至会降低哈希的安全性。永远不要尝试发明自己的加密货币，始终使用专家设计的标准。有些人会争辩说，使用多个散列函数会使计算散列的过程变慢，因此破解会更慢，但有更好的方法可以让破解过程变慢，我们稍后会看到。

以下是我在互联网论坛上看到的一些糟糕的古怪散列函数示例。
md5(sha1(password))
md5(md5(salt) + md5(password))
sha1(sha1(password))
sha1(str_rot13(password + salt))
md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))
请勿使用其中任何一种。

Salt 应使用加密安全伪随机数生成器 (CSPRNG) 生成。 CSPRNG 与普通的伪随机数生成器非常不同，例如“C”语言的 rand() 函数。顾名思义，CSPRNG 被设计为具有加密安全性，这意味着它们提供了高度的随机性并且完全不可预测。我们不希望我们的盐是可预测的，所以我们必须使用 CSPRNG。下表列出了一些流行的编程平台存在的一些 CSPRNG。 (PHP: mcrypt_create_iv, openssl_random_pseudo_bytes)

盐必须是每个用户每个密码唯一的。每次用户创建帐户或更改密码时，都应使用新的随机盐对密码进行哈希处理。切勿重复使用盐。盐也需要很长，以便有许多可能的盐。根据经验，让你的盐至少与散列函数的输出一样长。 salt 应该与哈希一起存储在用户帐户表中。

存储密码

使用 CSPRNG 生成长随机盐。

将盐添加到密码中，并使用标准加密哈希函数（例如 SHA256）对其进行哈希处理。

在用户的数据库记录中保存盐和哈希。

验证密码

从数据库中检索用户的盐和哈希。

将盐添加到给定密码并使用相同的哈希函数对其进行哈希处理。

将给定密码的哈希值与数据库中的哈希值进行比较。如果它们匹配，则密码正确。否则密码不正确。

在此页面的底部，有 PHP、C#、Java 和 Ruby 中的加盐密码哈希的实现。

在 Web 应用程序中，始终在服务器上散列

如果您正在编写一个 Web 应用程序，您可能想知道在哪里散列。密码应该在用户浏览器中使用 JavaScript 进行哈希处理，还是应该“以明文形式”发送到服务器并在那里进行哈希处理？

即使您在 JavaScript 中对用户密码进行哈希处理，您仍然需要在服务器上对哈希进行哈希处理。考虑一个网站，它在用户的浏览器中对用户的密码进行哈希处理，而不对服务器上的哈希值进行哈希处理。为了验证用户身份，该网站将接受来自浏览器的哈希值并检查该哈希值是否与数据库中的哈希值完全匹配。这似乎比仅在服务器上散列更安全，因为用户的密码永远不会发送到服务器，但事实并非如此。

问题是客户端哈希逻辑上成为用户的密码。用户进行身份验证所需要做的就是告诉服务器他们密码的哈希值。如果坏人得到了用户的哈希值，他们可以使用它来验证服务器，而无需知道用户的密码！因此，如果坏人以某种方式从这个假设的网站窃取了哈希数据库，他们将可以立即访问每个人的帐户，而无需猜测任何密码。

这并不是说你不应该在浏览器中散列，但如果你这样做了，你绝对也必须在服务器上散列。在浏览器中散列当然是一个好主意，但在您的实现中请考虑以下几点：

客户端密码散列不能替代 HTTPS (SSL/TLS)。如果浏览器和服务器之间的连接不安全，中间人可以在下载 JavaScript 代码时对其进行修改，以删除散列功能并获取用户密码。

有些网络浏览器不支持 JavaScript，有些用户在他们的浏览器中禁用了 JavaScript。因此，为了获得最大的兼容性，您的应用应检测浏览器是否支持 JavaScript，如果不支持，则在服务器上模拟客户端哈希。

您还需要对客户端哈希值加盐。显而易见的解决方案是让客户端脚本向服务器询问用户的盐。不要那样做，因为它会让坏人在不知道密码的情况下检查用户名是否有效。由于您也在服务器上进行散列和加盐（使用良好的盐），因此可以使用与特定于站点的字符串（例如域名）连接的用户名（或电子邮件）作为客户端盐。

来源：https://crackstation.net/hashing-security.htm

所以，回答你的问题，坏主意，非常坏的主意。

【讨论】：

写得很好，引文很好——继续努力。我真的认为最好的想法是推荐新的password_hash API，它确实抽象了大多数开发人员必须考虑这个问题。你可以use it with older PHP too。
你链接的文章也不错，但是在这里复制粘贴有什么意义呢？
@thg435 答案应始终包含链接源的重要部分，因为即使其他站点移动或删除链接文档，我们也希望答案有效。（请参阅帮助 (stackoverflow.com/help/how-to-answer) 中的“为链接提供上下文”
@Gus：链接和引用很好，复制粘贴大块外部文本则不行。

【解决方案2】：

请永远不要这样做。加盐的全部意义在于每个人的密码哈希都是唯一的，这消除了彩虹表的问题并泄露了谁拥有相同的密码。

为什么这很重要？看看他们有“密码提示”的LinkedIn hack。人们有像“rhymes with assword”这样的提示，它泄露了他们的密码，以及他们的哈希值。它还泄露了使用相同密码的其他所有人。

【讨论】：