使用散列的最后字符作为盐类

Question

在最近的一次讨论中，有人提到了以下哈希方案：

passHash = sha256(password)
saltedHash = sha256(passHash+passHash.substr(-10)
finalHash = sha256(secret+saltedHash)

对密码进行散列，然后再使用前一个散列的最后10个字符进行散列，作为“盐分”。最后，附加一个秘密，并在将其保存到数据库之前再次对所有内容进行散列。

这有多安全？我知道相同的密码会有相同的finalHash。但除此之外，使用部分散列密码作为salt有多糟糕？以后吃点秘密盐有帮助吗？只有3次sha256迭代而不是几千次迭代有多糟糕？有什么简单的攻击可以证明这个哈希计划是胡扯吗？

Answer 1

不要这样做。盐必须是独一无二的，这是它们唯一的要求。但是你的方法并不产生唯一的盐，而是依赖密码的盐。

当每db唯一的盐类足够长(256位)时会有所帮助，您还可以在用户名中进行散列，但这仍然会留下问题。

只有3次SHA256迭代并不是密码哈希应该采用的方式，尽管它不仅仅是“更高即更好”。如果攻击者忙于执行大量的sha迭代，他们就无法尝试新的密码。确保您使用PBKDF2或类似的方法来防止进一步的攻击。您可以从迭代计数中取对数2，然后就可以得到破解密码所需的附加的“安全性”。迭代可以在计算能力和安全性之间进行权衡，但是转换速度非常低(1:1而不是1:exp和密码长度)。

你所做的不是腌制，它烘焙一个新的哈希功能从另一个。对于每个用户，从PRNG中创建一个包含256位熵的随机字符串，并将其用作salt。

Answer 2

简短的回答:不要这样做。

应该使用Salt来提供一些针对泄漏的散列密码的安全性，因为相同的密码在未加盐时将具有相同的散列。

如果盐是可预测的，就没有收获。

因为这样做没有增加任何熵，所以做这样的事情是没有好处的。

而且由于你使用的迭代次数非常少，它只剩下太快而不能被使用的密码SHA-256，很容易出现你在问题中提到的所有弱点。

Answer 3

你的“盐”似乎没有提供任何好处，这是使用盐的意义。使用您的方案，每个密码只生成一个输出，因此，知道您的方案(您必须假设他们会这样做)的攻击者可以轻松地生成一个包含可能散列的彩虹表，以便与数据库中的哈希匹配。

salt应该用来防止这种情况，因为每个密码的salt不同意味着，即使它们是相同的密码，结果的散列也是不同的，因此生成彩虹表是不可行的，因为它不仅需要包含每个可能的密码的散列，还需要包含密码和salt的每个可能组合的哈希。

正如其他人所说，SHA256的3次迭代仍然会执行得太快。您应该使用专门为哈希密码(如BCrypt )设计的机制。即使您使用的机制比较慢，您也不应该永久地将自己与单个速度或迭代次数联系在一起；计算机速度总是在增加，您会希望增加迭代次数以保持领先。BCrypt允许您在不破坏现有散列的情况下做到这一点，因为它将存储的强度与散列密码一起编码。