Hash 密码+；盐+；沙司？有帮助，还是有点默默无闻？

标准密码安全性涉及为每个用户生成一个随机salt，以某种方式将该salt与他们的密码组合并将它们散列在一起，然后将散列和salt存储在数据库中

如果您不仅添加了

散列（$salt.$password）

，还添加了另一个密码短语（仅存储在源代码或服务器配置文件中），而不是：

$secret_sauce = 'tehB%l1yG*@t$G2uFf'; // perhaps imported from config file
$hash = hash($salt . $secret_sauce . $password);

---

这是否增加了任何额外的好处，或者只是在顶部应用了一层薄薄的隐蔽性安全措施？

对于密码文件，只是在顶部添加了一点隐蔽性

---

然而，这个方案被称为“密钥散列”，可以用于对称（共享秘密）签名：如果您有这样的散列和输入数据，那么您可以确保签名是由也知道秘密额外位的人创建的。当然，与公钥签名不同的是，在不知道密钥的情况下，您无法验证这一点。

我在追踪几年前读到的一篇文章时遇到了困难，这篇文章指出，通过部分计算散列，可以轻松生成数千个散列结果。（如中所述，通过开始计算“foo”的散列，您可以更轻松地为“foo1”、“foo2”、“foo3”、“foo4”等生成散列，这比单独生成每个散列要便宜得多。）

我认为在密码之前和之后加盐都是有道理的

---

但是请记住，如果密码数据库可以被攻击者读取，他们可能也可以从二进制文件或配置文件中读取salt；这取决于你的设计。

关于你的最后一段：我读了好几处，但我不明白为什么。我想我真的不知道一开始攻击者通常是如何访问数据库的。（我认为SQL注入是一种可以访问数据库，但不能访问服务器上的文件的方式）。@keithjgrant，如果这是你最大的威胁，那么额外的盐分是有意义的呵呵。触摸。那么，对于攻击者找到一种方法通过ssh进入服务器并获得对数据库、文件和所有内容的访问，人们是否普遍感到担忧呢？为什么我可以假设如果他们可以读取数据库，他们可以读取文件？不可能总是这样的，不是吗？@keithjgrant，你说得对，利用漏洞暴露数据库也不一定会暴露程序。我当然不想依赖程序二进制文件被隐藏作为重要的安全功能，但这只是为了使密码暴力搜索复杂化（或者寻找具有相同密码的服务，如果在两个被破坏的系统上使用相同的密码和salt！）我认为这不仅仅是合理的“纵深防御”技术。