关于加盐密码的问题答案

【问题标题】：Questions about salting passwords关于加盐密码的问题
【发布时间】：2011-01-13 06:35:09
【问题描述】：

好的。例如，我将密码的 salt 设置为“hello”。有人不能只看源代码并发现盐吗？如果是这样，我将如何隐藏它？谢谢。

【问题讨论】：

你需要与你不信任的人分享你的源代码吗？
请记住，如果他们能看到您的代码，那么您的网站已经被入侵了。他们可能也可以访问您的数据库。您不再保护您的应用程序，而是保护用户的密码（大多数用户在他们使用的所有网站上都使用一个密码）
@SRM：所有（字符串）哈希都有冲突。
@SRM：事实上，所有散列到有限位数的散列将发生冲突。事实上，有无限可能的输入，映射到有限数量的输出，保证有两个输入将提供相同的输出。
@Anon 好的，好的。我承认。你是对的，我的说法是错误的。我已经删除了它们。

【解决方案1】：

Salts 通常以纯文本形式存储在密码哈希旁边。它们存在的主要原因是使使用预先计算的rainbow tables 变得更加困难，并且更难以对数据库中的所有密码执行dictionary attack。

您还应该为每个密码使用一个不同随机生成的盐，而不是为整个应用程序使用一个盐。这意味着每个密码都必须单独破解。

【讨论】：

这也是为什么它们应该超过 5 个字符，并且由一些非字母字符组成。为每个用户使用单独的盐也有帮助。
@Mchl：Salts应该对每个用户都是唯一的。盐的全部意义在于，攻击者需要单独攻击每个哈希，而不是计算大量彩虹表并针对整个用户数据库运行它。使用站点范围的盐可能比不使用更更糟糕，因为你认为你有一些安全性，而实际上你并没有。

【解决方案2】：

首先：安全性很重要。不要尝试自己做，因为你会搞砸了。使用完善的库来处理用户身份验证。

其次，您似乎误解了盐的用途。 salt 只是为了防止密码哈希值被轻易反转 - 每个用户都应该有一个唯一的 salt，但可以将 salt 存储在与哈希密码相同的位置。

【讨论】：

【解决方案3】：

Salt 最好是动态的（比如成员的加入日期）。即使攻击者知道你计算哈希的方式，他们也必须暴力破解每个加盐和哈希的密码——这需要很多时间，因为（通常）小奖励。

话虽如此，如果攻击者正在查看您的服务器端代码，那么您已经遇到了很多更大的问题。

【讨论】：

【解决方案4】：

1) 不要为多个帐户使用相同的盐。如果您不能显示您的源代码并相信您的密码仍然是安全的，那么您做错了。

【讨论】：

【解决方案5】：

希望您的“源代码”在网络服务器上运行，而不是在任何人都可以看到的客户端 (javascript) 上。

【讨论】：