密码哈希的盐也应该“散列”吗？答案

【问题标题】：Should the Salt for a password Hash be "hashed" also?密码哈希的盐也应该“散列”吗？
【发布时间】：2011-04-29 08:44:12
【问题描述】：

我认为这可能是一个愚蠢的问题，但我已经很困惑我应该在这里做什么才能做到最好。

在对密码哈希进行加盐处理时，盐是否也应进行哈希处理或保留为明文？

注意：我在 SHA-256 中对密码进行哈希处理，Salt 是一个预定义的字符串，因为一次只能存储一个密码。

TIA

克里斯（香巴拉）。

【问题讨论】：

标签： security delphi passwords

【解决方案1】：

盐不应该被散列，因为你需要在散列之前将原始值与密码结合起来。

【讨论】：

【解决方案2】：

没关系。

盐的目的是防止预计算攻击。

无论是散列盐还是单独使用盐，都会导致每次添加相同的数据作为盐。如果你对盐进行哈希处理，那么你实际上所做的就是改变盐。通过首先对其进行哈希处理，您可以将其转换为不同的字符串，然后将其用作盐。没有理由这样做，但这样做也不会做错任何事情。

您只需要保持一致并且每次都使用相同的方法，否则您最终会得到不同的密码哈希。

【讨论】：

我仍然强烈建议不要使用静态盐。即使您一次只存储一个密码，它也可能违背了使用盐的目的。
我同意，每个密码可能应该使用不同的盐，您只需要每次对给定用户的密码使用相同的盐。但这里的重点是盐只是额外添加的东西。在使用之前对盐进行哈希处理不会改变这一点，它只会让它变得与众不同。
这是语义，但你不能散列盐。盐必须以明文形式检索才能使用。由于哈希是一种方法，因此您不能对盐进行哈希处理。如果您想使用散列算法生成盐，那很好，但生成的散列值将成为新的盐，您仍然必须能够以明文形式检索它。如果你真的散了盐，你就失去了你的帐户。

【解决方案3】：

你不能散列盐，因为散列是一种方法。您需要盐，以便在散列之前将其添加到密码中。您可以对其进行加密，但这不是必需的。

关于盐的关键是每个密码都应该有自己的盐。理想情况下，每种盐都应该是唯一的，但随机也很好。因此，盐应该足够长，以使其对于每个密码都是唯一的。

如果所有的盐都相同，那么破解者（谁可以看到您的哈希值）很明显，哪些帐户具有相同的密码。哈希值将是相同的。这意味着如果他们破解一个密码，他们无需额外工作即可获得多个帐户。破解者甚至可能针对这些帐户。

你应该假设破解者将获得盐和哈希值，所以哈希算法必须是安全的。

使用任何盐可以防止使用现有的预先计算的彩虹表来破解您的哈希值，并且为每个帐户使用唯一的盐可以消除您的破解者使用您的盐预先计算自己的彩虹表的愿望。

【讨论】：

@aaaa bbbb，如果在存储盐之前对其进行哈希处理，则无法检索密码。如果您在生成盐时使用散列算法，那很好。盐是在散列值之前添加到明文中的部分。在此之前它不是盐。

【解决方案4】：

不，您不能对盐进行哈希处理。盐是明文形式，您需要重新计算密码并与存储在散列密码文件中的密码进行核对。

但是如果你需要一个强加盐程序，你可以用这种方式计算你的加盐密码：

SaltedHashedPwd = H(H(H(H(.....H(PWD-k+SALT-k)+SALT-k)+SALT-k).....)+SALT-k+N

H 是哈希函数 SALT-k 是您用作盐的 k 随机字符串 PWD-k 是 k 密码（每个密码都有不同的盐） N 是你组成 H 函数的迭代次数

在 PKCS#5 标准中，它使用 N=1000！

在这种情况下，字典攻击是不可能的，因为对于字典中的每个单词和密码文件中的每个 SALT，攻击者都需要计算哈希值。时间太长了！

我认为 N=100 应该足够你使用 :-)

【讨论】：

错了。 “没关系”是正确答案。您可以对盐进行哈希处理，这实际上为您提供了一种有效的新盐。您所要做的就是保持一致。
更好地了解我写的内容。您可以将 PWD 和 SALT 连接起来，但最后您必须连接 SALT 的清晰形式。否则您无法在验证阶段重新计算哈希。

【解决方案5】：

由于盐需要与散列一起保存（或至少必须与散列一起被检索），攻击者可能会同时获得盐和散列密码。在我的一些应用程序中，我已将盐加密存储在数据库中（使用只有应用程序知道的密钥）。我的理由是，将未加密的盐与散列密码一起存储将更容易破解密码，因为能够检索密码表（并且会知道或对散列算法做出假设）的黑客将能够通过散列字典中的每个单词，然后用他也可以访问的盐进行加盐，来找到众所周知的单词散列之间的匹配（字典攻击）。如果盐是加密的，那么除非他还可以访问应用程序已知的加密密钥，否则这种攻击是不可能的。

（如果有人看到这个逻辑有问题，请发表评论。）

【讨论】：