这取决于哈希函数。

使用随机预言机（这是“理想的哈希函数”），只要两者都进入，你如何将盐和密码放在一起就没有区别。

使用实时哈希函数，输入的位置可能会有所不同（例如，存在扩展攻击）。

但是，您通常希望使用一些特殊的密码散列方案，如 PBKDF-2、bcrypt 或 scrypt，这些已经由三个输入组成，一个是密码，另一个是盐（第三个是工作因素）。只需按照它们的用途使用它们。

这篇文章的意思是，将盐放在密码中间的某个地方可能会增加被字典攻击或蛮力破解的机会，因为实际组成相同哈希的规则无法在您的密码中实现首选饼干。实际上，这可能完全是胡说八道。

这是如何运作的？

如果你使用像John the Ripper这样的程序，你可以用你的密码文件来输入它（不是确切的语法）：

username:password:salt

然后，您将格式作为您认为生成哈希的参数传递。这可以是：

md5(pass + salt)
md5(salt + pass)
md5(md5(pass) + md5(salt))
md5(pass + md5(salt))
md5(md5(...(salt + pass + salt)...))
...
and whatnot.

John the Ripper 带有一组预制的大约 16 种子格式，您可以从中进行选择。

将盐放在密码中的某个位置可能看起来像这样：

md5(password.substring(0,4) + salt + password.substring(4,end))

因此，使用这样的技术需要您首先为 John 编写一个小插件，然后才能开始破解（这根本不应该成为问题）。

此外，作为攻击者，您可能拥有一个哈希列表 + 未知来源的盐，并且不知道哈希的组成方式。这种情况很少见。如果您作为攻击者设法从数据库中提取哈希和盐，您可能会找到一种方法来提取网站的密码哈希算法，或者您只需使用已知密码创建一个新帐户，提取哈希和盐它并暴力破解用于组成最终哈希的算法（这可能或多或少具有挑战性）。

总而言之，将盐放在哪里以及是否将散列算法迭代一万次几乎是完全任意的。这不会提供大量的安全性。

如果你想要安全，你可以通过使用更好的散列算法或 bcrypt 或其他计算成本高的东西来做得更好。

在输入字符串的开头最好有随机性，而不是在结尾。

如果盐是所有密码的常数值，那么如果盐应用为：

hash(salt . password)

而不是

hash(password . salt)

原因很简单，因为某些（我认为 md5 和 sha-1 都符合此描述）散列算法是迭代的 - 如果您要散列的字符串以已知的常量值开头，则可以使用以下结果为任何破解尝试播种散列盐，从而消除加盐密码的好处。

如果 salt 值是特定于密码的（它们应该是），则上述内容不适用，并且 salt 可能比密码本身更随机。出于这个原因，最好预先添加盐 - 尽管差异/好处可以忽略不计。

在输入字符串中间插入盐的建议可能是不以常量值开始输入字符串的另一种排列 - 只要您避免这种情况，密码就与散列算法和使用它的应用程序一样安全。

它可能会更安全一些，但可以忽略不计。我不会担心它，只是为了简单起见把它放在前面。几乎我工作过的每家公司都没有使用盐，所以你已经比大多数公司更安全了。

与未加盐的散列相反，未加盐的散列可能很容易被彩虹表破解。