散列哈希是不是使其更安全？ [复制]

Posted 2023-02-24

【中文标题】散列哈希是不是使其更安全？ [复制]

【英文标题】：Does hashing a hash make it more secure? [duplicate]散列哈希是否使其更安全？ [复制]

【发布时间】：2012-11-14 23:02:23

【问题描述】：

可能重复：Is “double hashing” a password less secure than just hashing it once?

我在 php 中使用 sha1 加密密码，但我想知道散列散列是否比仅散列密码更安全。

例如：

是

$hash = sha1($pwd);

安全性低于

$hash = sha1(sha1($pwd));

我不明白为什么会这样，因为反向查找网站将无法找到哈希值的匹配项。

【问题讨论】：

看看***.com/questions/348109/…

快速 SHA 在各种地方都很有用，密码存储不是其中之一。密码散列应该使用昂贵的计算算法来完成，例如 PBKDF2。

被标记，希望它不仅会被关闭，而且会被传输到加密货币中。我将就此创建一个关于 META 的讨论。

@owlstead 我很确定我们有很多重复的地方。在这里，在 crypto.SE 和 security.SE 上。我不认为迁移在这里有用。

@CodesInChaos 嗯，太真实了。在其他网站上检查欺骗和转移问题的方法有点不方便，因此即将在 META 上发布。

【参考方案1】：

双重哈希并没有真正的帮助。 Salting 会。

【参考方案2】：

为确保您的密码存储安全，您不应使用sha1 或任何其他快速哈希算法，而应使用密钥派生函数，如BCrypt。

快速算法的问题在于，您可以使用普通硬件 (in 2012) 每秒计算 3 Giga sha1-hashes。这使得在不到一毫秒的时间内暴力破解大约 500000 个单词的整个英语词典成为可能！

您示例中的第二个问题是缺少盐。如果您不为每个密码使用唯一的盐，攻击者可以构建一个彩虹表来获取所有密码。

BCrypt 专门设计用于散列密码，因此慢（需要一些计算时间）。通过成本因素，您可以将所需的时间调整到未来（因此更快）的硬件上。在内部，它会按照您的建议执行类似的操作，它会重复散列很多次，但以安全的方式。

使用 BCrypt 就像使用 sha1 哈希一样简单。 PHP 5.5 将拥有自己的函数password_hash() 和password_verify()，以简化此任务。还有一个适用于 PHP 5.3/5.4 的 compatibility pack，可在 password_compat 下载。

【参考方案3】：

首先，与 sha1 一样弱的是它比明文存储的密码更好。任何加密、散列或其他混淆都比明文好得多！

sha1 的问题在于它的速度很快，因此它可以快速生成要破解的哈希值。加盐有很大帮助，但是如果您的服务器受到威胁并且您将盐哈希存储为某个字符串，那么就会有这个优势......

如果你不想使用 mcrypt 或其他加密方法，你可以像这样混合你的 sha1 哈希：

$my_super_sha1_hash = 
sha1(
    sha1(
        substr(
            sha1($username)
            , 0
            , strlen($password) 
        )
    )
    .sha1(
        substr(
            sha1($password)
            , 0
            , 40-strlen($password)
        )
    )
);

通过将用户名和密码混合在一起，并使用（未知）密码的长度来确定每个位在 sting 中使用的哪些位，然后再次进行哈希处理，每个盐是唯一的，但不是随机的，所以结果是在所有用户之间保持一致，并且由于必须考虑密码和用户名的字符串长度，因此更难破解。

【讨论】：

这比仅对用户名和密码的连接进行哈希处理不安全。

你错过了盐的重点。这不是秘密，每个哈希阻止多目标攻击的方式不同。如果攻击者知道盐，它仍然是有益的。 （尽管除了每个用户的唯一值之外使用未知值是一个额外的优势）。您还忘了提及密钥强化，即使用对攻击者来说计算成本很高的哈希函数。

你的混音方案也很愚蠢。对于短密码，盐空间变得非常小，对于长密码，密码的贡献消失了，对于非常长的密码，代码甚至无法正常工作。您的方案显然不如简单的sha1(sha1(username).sha1(password)) 甚至只是sha1(username."|".password)

这篇文章并不是说“这是一个超级安全的函数，使用它就可以了”，它只是关于 sha1 太弱了，任何自制的 sha1 哈希解决方案都需要大大增加复杂度。在我看来，与在哈希旁边存储随机生成的盐相比，沿着这些线的函数具有优势，因为如果 db 用户表被盗，盐仍然是未知的，并且根本不会向攻击者提供有关计算的任何提示方法，同时仍然给每个密码一个唯一的盐。

我看不出这比简单的用户名和密码连接更不安全。如果被盗的 db 哈希确实设法被反转并且他们看到了 80 字符的双 sha1 连接字符串，那么完整用户名或密码的直接 sha1 的子字符串将比部分用户|密码哈希的哈希更明显。如果 php 哈希代码被泄露，这一切都毫无意义，因为攻击者可以只运行哈希函数，在这种情况下，至少它会比你建议的简单 concat 计算成本更高。