在密码加密中使用随机盐？答案

【问题标题】：Using a random salt in password encryption?在密码加密中使用随机盐？
【发布时间】：2011-04-30 13:57:19
【问题描述】：

我已经看过一些关于这个主题的其他主题，但对于涉及在密码加密中使用随机盐的一些问题，我似乎找不到一些答案。据我了解，步骤如下：

为用户生成随机盐。
将盐添加到他们的密码中。
使用 SHA-2 之类的方法对结果进行哈希处理。
在数据库中存储盐和哈希密码。

在检索用户密码和验证登录时，此方法如何工作？一个回应说应该检索用户的盐，附加到他们输入的密码，散列，然后与存储的散列进行比较，但这不会引发一些问题吗？即：

如何在不影响该用户的情况下检索盐？如果有人想暴力破解某个账户的密码，难道他们不能检索从服务器发回的盐对输入的密码进行哈希处理，从而消除使用盐增加的安全性吗？
如果我们通过在服务器端进行 salt 检索来避免前面的问题，那么我们是否会在某一时刻发送未加密的用户输入密码（以便以后可以将其附加到检索到的 salt 中）？

【问题讨论】：

标签： database encryption hash passwords

【解决方案1】：

我使用在应用程序代码中硬编码的固定盐（适用于所有密码）。假设盐不能暴露（例如通过应用程序的 UI），这看起来很简单且足够好。

【讨论】：

问题是，对于像网站这样的东西，硬编码盐不起作用，原因有两个：a) 如果盐是在客户端添加的，它对任何人都是公开可见的，并且所以它完全没用，b）如果它是在服务器端完成的，则必须以未加密的方式发送用户的密码，以便它可以在服务器端完成，因此在任何一种情况下都有一个巨大的缺陷。
是的，你是对的。我觉得最好在服务器端加盐，在传输密码的时候客户端使用https。
但这意味着，如果散列密码被泄露，攻击者可以并行攻击所有密码——加盐就是为了防止这种情况。 IE。使用每个用户的盐，那么每个哈希计算只能与该用户的哈希结果进行比较。但是对于应用程序使用单一的盐，每个哈希结果都可以与所有用户进行比较。而且，如果哈希值被公开，两个不同的用户可以确定他们拥有相同的密码。
@Damien_The_Unbeliever：你的意思是盐和散列密码是否被泄露。如果攻击者获得了对服务器的访问权限（以便通过对应用程序代码进行逆向工程来定位 salt），那么您还需要担心其他问题 :)
@cherouvim - 用户仍然可以确定其他人共享相同的密码，而不会影响盐。如果该其他用户是管理员，这可能是一个问题。而且你不应该有隐藏盐。如果他们通过无意中发布您的源代码而不是服务器妥协来检索盐怎么办？如果不使每个人的密码失效，您就无法更改盐。

【解决方案2】：

salt 引入的安全性是，您可以获得比普通密码更大且非标准的哈希值。它的算法是否关闭并不重要，因为它可以保护存储在数据库中的普通哈希免受彩虹或字典攻击。

还建议递归地多次取哈希，可能在每次迭代时读取盐，这样蛮力会花费更长的时间。

编辑：Bevan 所说的关于通信的内容：通常“使用一次的号码”（NONCE）方案用于通过不安全的渠道传输密码。服务器将一个以前从未使用过的随机字符串提供给客户端，客户端将其附加到纯密码，计算哈希并发送。这可以保护您免受窃听攻击。

【讨论】：

但是如果盐是固定的或者算法是关闭的，那么像字典攻击这样的东西就不能通过简单地将已知的盐附加到每个尝试中来克服吗？
嗯，RE算法并不难，所以不要因为它被关闭而感到安全。

【解决方案3】：

散列密码可以防止明显可见的密码，而加盐可以防止字典攻击。至于在传输过程中保护密码，我建议使用 SSL/TLS。

【讨论】：

向您推荐这个简单但完全正确的答案。人们用加盐使事情复杂化了——目的之一是防止字典（“原像”）攻击，仅此而已。人们经常认为增加的盐的长度增加了某种不正确的安全性，并且他们还错误地经常认为如果盐和哈希被破坏就等于根本不使用盐，事实也并非如此.即使同时使用盐和哈希，这也会增加大量计算，必须针对字典中的每个单词测试每种盐！

【解决方案4】：

不发送可用于登录的未加密值的唯一方法是使用 SSL。如果散列被发送到服务器，散列本身可以被嗅探并用于登录。做服务器端。

+1 对 ruslik 所说的盐。它可以防止字典/彩虹攻击。平均密码 + 几个字节的随机二进制数据的彩虹表将是天文数字。

【讨论】：

+ 它已经不存在了。常见哈希函数和常见单词和/或特定大小单词的彩虹表已经存在。

【解决方案5】：

盐永远不应该暴露在服务之外 - 你的直觉是正确的，这会暴露盐并引入风险。

您的客户端和服务器之间的任何通信都应通过 SSL 连接进行 - 或至少使用某种交互加密。

请记住盐的用途：使某人更难预先计算哈希码，从而在数据库受到破坏的情况下能够查找密码。 8 位盐使散列空间大 256 倍，使预计算变得更加困难。盐不是为了确保通信安全 - 还有其他解决方案。

【讨论】：

即使盐渍算法被暴露，系统也应该是安全的。你提出的是“通过默默无闻的安全”，它从来都不是安全的。即使你知道它们，所有好的加密算法都是安全的。
@ruslik 对不起，我不明白你的意思。当然，算法应该公开——这是良好安全性的公理。 “盐”是指特定密码的实际盐值，而不是加盐算法。
@Bevan 抱歉，没有区别。
@ruslik 我的理解（总是需要更正）是盐的作用是提供额外的密钥位，并且像任何对称密钥一样，应该保密。维基百科同意（“为了最好的安全性，盐值是保密的。”en.wikipedia.org/wiki/Salt_%28cryptography%29）。你觉得我错过了什么？
@Bevan 在我的理解中，如果算法被公开（假设它可以在客户端的机器上生成），你不能保密。

【解决方案6】：

您必须使用随机盐，因为使用它的目的是防止某些类型的攻击，例如字典攻击、蛮力攻击和彩虹攻击。因此，为每个密码生成随机盐并将散列密码和盐存储在用户表中或附加到用户配置文件中非常重要。当您想验证用户密码时，只需使用存储的盐对输入的密码进行哈希处理并与存储的哈希值进行比较即可。我不相信@cherouvim 的建议，因为他似乎并不关心上述攻击。有关更多信息，我建议Defuse Security 撰写一篇精彩、简单且易于理解的文章

祝你好运。

【讨论】：

1.为每个用户创建随机盐 2. 使用该盐加密密码 3. 将密码存储在数据库中 4. 使用固定的普通盐加密盐，保存在您的配置文件中。 5. 将加密的盐存储在数据库中。