静态盐与随机盐 - 安全 PHP答案

【问题标题】：Static Salt vs Random Salt - Security PHP静态盐与随机盐 - 安全 PHP
【发布时间】：2011-05-08 18:05:55
【问题描述】：

两者之间有什么工作区别

$hash=sha1($key.$staticSalt);

和

$hash=sha1($key.$randomSalt);

如果我使用随机盐，我需要将随机盐存储在数据库中，另一方面，如果我使用固定盐，则无需使用数据库！
如果可以破解代码以查看盐（静态），那么黑客也可以通过哈希和随机盐查看数据库：D
那么值得吗？
如果我使用像 @#kiss~89+.&&^me 这样的盐怎么办？

【问题讨论】：

【解决方案1】：

随机盐有一个巨大的好处。如果系统中的所有帐户都使用相同的盐，攻击者可以暴力计算该盐的哈希值，并通过一次计算运行闯入所有帐户。如果他们每个帐户使用不同的盐，暴力破解只会让您进入一个帐户。

【讨论】：

如果他（黑客）可以得到密码，那么他就可以下载完整的数据库。并且获得对数据库的控制 [几乎] 也意味着获得对代码的访问权限！所以他也可以更改我的代码以登录任何帐户！ 如果我错了，请纠正自己！
你确实错了。访问数据库并不（不应该！）意味着访问代码。您还错误地假设只能通过获取 db 密码来访问数据库。其他攻击也是可能的，包括可能暴露哈希但不一定暴露所有数据的 SQL 注入。
哦，是的，sql注入是可能的。但是你不认为有人真的很幸运才能发现我用的盐吗？
@Sourav 获得 DB 转储的好处不是能够像一些可怜的傻瓜一样登录。人们有在所有帐户中使用相同密码的习惯。如果您不是在 IT 安全相关职位上工作，那么即使您也很可能会更改 3-5 个密码。

【解决方案2】：

虽然密码存储的最佳实践要求它们应以具有唯一盐的散列格式存储，但最初的问题实际上提出了一个相当好的观点：如果将盐存储在与散列不同的位置，则影响那些被披露的哈希值被降低了。

1) 如果密码仅经过哈希处理，并存储在数据库中，并且网站遭受 SQL 注入攻击，那么攻击者可以“破解”哈希

2) 如果密码使用盐进行散列，并且散列和盐都在数据库中，并且该站点具有 SQL 注入，那么攻击者可以“破解”散列，但需要更多的计算工作（因为那里预先计算的表没有性能提升）

3) 如果密码是带有盐的哈希值，并且盐存储在其他地方，那么 SQL 注入将无法为攻击者提供确定实际密码的任何手段。

场景 1 显然最弱，但 2 和 3 之间的安全性差异不太明显，并且取决于 SQL 注入与服务器端代码泄露（以及相关的漏洞类别）的相对概率。

您更信任什么 - 防止 SQL 注入的能力，或 Apache/PHP/Whatever 保护服务器端内容的能力。

事情从来都不是简单的，我实际上认为 OP 中的想法比其他答案更有意义。

（在生成密码时，您可以同时使用存储在数据库中的盐和“密钥”（如果您喜欢存储在 Web 应用程序源中）。

【讨论】：

【解决方案3】：

根据定义，盐是随机的；没有“静态盐”之类的东西。如果它不是随机的，则它不是盐而是密钥。

加盐的目的是确保攻击者必须对他/她想要破解的每个密码进行单独的攻击。换句话说，加盐哈希的目的是防止预计算攻击 (rainbow tables)。

正确的解决方案是使用standard library 而不是偷工减料

【讨论】：

【解决方案4】：

始终为每个密码使用随机盐。

如果你不这样做，那么吃盐的好处就会失去。如果您使用相同的盐，那么在网站遭到入侵的情况下，黑客可以使用相同的哈希表来破解您用户列表中的所有密码。如果 salt 是随机的，那么他们必须为每个用户使用不同的哈希表。

【讨论】：

【解决方案5】：

我不确定您的加盐是否正确——加盐的目的是在您的数据库遭到破坏时阻止预先计算的字典攻击。因此，您开始使用数据库，那么您的“无需使用数据库”评论是什么意思？

如果您没有使用随机盐，那么如果攻击者掌握了盐，您不会使攻击者更难攻击您的哈希值。使用随机盐会更好——您无需将其隐藏以确保安全工作。

盐也不需要太长或不寻常。 “rK”是一种很好的盐。 “1q”也不错。它的目的只是改变散列函数的输出。

【讨论】：