HMAC 是一种消息验证码，用于验证完整性。这是一种完全不同的野兽。

然而，碰巧 HMAC 是建立在散列函数之上的，并且可以被认为是“键控散列”——一个带有key的散列函数。密钥不是盐（密钥是秘密的，盐不是）。但是 HMAC 的独特特性使其成为其他功能的合理构建块，这就是PBKDF2中发生的情况：这是一个密钥派生函数，通常被颠覆为密码散列（它似乎足以胜任的角色）。PBKDF2 包含一个salt，并在内部调用 HMAC（多次）。

好的密码散列必须很慢（以可配置的方式）并包含salt。这些特性并不容易获得，而且您不会从单独的 HMAC（速度快且不使用盐）中获得它们。

简短的回答：

有点，但不是真的。加盐只是在散列之前添加到消息中的随机数据，其目的是使加盐消息产生的散列不同于攻击者可能已经用相同但未加盐的消息（或任何其他消息）自己计算的任何内容盐，就此而言）。通常，盐必须是公开的，以便根据需要合法地计算秘密消息的正确哈希值。公共消息的“秘密盐”，用于产生防篡改的经过验证的散列在理论上是可行的，但实际上我们的散列函数是不完善的，当以这种方式使用时，它们很容易受到将数据添加到原始消息的攻击并以可预测的方式更改哈希（“长度扩展攻击”）。

HMAC 以密钥的形式包含额外的秘密数据。此密钥以比盐更深的方式与消息结合，并且可以在消息的简单盐之外使用。最终结果不会像带有秘密盐的简单哈希那样容易受到相同的攻击，因此生成经过身份验证的哈希的方法要强大得多。

更长的答案：

散列（任何散列）的基本目的是模拟“随机预言机”；一个概念黑盒，可以给定任何消息，并将产生一个真正随机的、真正唯一的摘要值来识别它，如果给定相同的消息，它将产生相同的随机值。在许多加密应用程序中都需要这种类型的函数，它们都以一种略有不同的方式使用随机预言机。不幸的是，不存在真正的随机预言机，因此具有已知和固有弱点的哈希函数必须足够好。

“散列加盐密码”是一种用途。这个想法是消息（密码）是一个秘密。散列值允许某人向系统证明他们知道正确的密码，而系统不必记住实际密码（使其易受攻击）。从理论上讲，只需将消息提供给随机预言机并为其取回真正唯一的值就足够了，但是因为我们没有随机预言机并且必须使用散列函数，所以可能的摘要值的数量是散列函数can generate 是有限的，所以理论上人们可以简单地找到一条消息，任何消息，它会产生每个所需的散列，并记住所有这些，这样他们就可以查找观察到的散列并找到会产生它的消息。盐使这个理论变得更加困难，和盐来产生观察到的哈希值。盐值必须是公共信息，因为在合法散列秘密消息时必须使用正确的盐；这使它与密钥不同，密钥必须保密以确保方案的安全性。

然而，Thomas 对密码散列的观察是非常正确的。用户选择的密码本质上是低熵的，因此即使在加盐的情况下也相对容易被暴力破解。为了阻止这种情况，需要额外的安全性，这通常以“密钥拉伸”的形式出现；添加了计算成本高的转换，以使生成单个哈希更慢（不会太慢以至于影响合法用户）。为每个哈希添加的工作使得重复哈希计算数十万次以暴力破解密码对于攻击者来说是站不住脚的。仍然需要加盐，因为避免按需执行此工作的最简单方法是提前完成并记住结果，就像使用“更快”的哈希算法一样。

HMAC 的用途略有不同。这个想法是消息可能不是秘密的。因此，如果使用基本哈希，很可能不会涉及任何秘密。这不是闻所未闻的事态。文件校验和是免费提供的，用于生成它们的文件也是如此，但校验和哈希通常受到保护，不会被修改。但是，如果不能保证摘要是“只读的”，例如，如果它与消息一起发送，则散列没有值，因为它被简单地更改以匹配它发送的任何消息。必须在流程中重新添加一个秘密，以确保只有知道该秘密的人才能使用该消息（或任何消息）以产生匹配的哈希。HMAC 将消息（仍然可以加盐）与密钥结合起来，为我们提供了这样的秘密。

现在，公平地问为什么不能简单地将盐值作为密钥保密，并在使用原始安全散列函数对其进行散列之前将其连接到消息。答案与“我们没有随机预言机”这一点有关。如果我们确实有一个随机预言机，那么我们可以对一些消息保密，并且预言机将永远不会在给定消息的其余部分的情况下产生相同的值（甚至是可预测的值），除非我们将它与我们的确切秘密重新组合已扣留。然而，对于我们现实世界中的大多数“安全”哈希函数，有一个已知漏洞允许进行称为“长度扩展”的攻击。给定一个任意长度的散列摘要，以及产生它的散列原语的知识，在许多情况下，在不知道整个原始消息（在我们的例子中包括连接或异或的“秘密盐”）的情况下，可以生成对应于将已知数据附加到消息末尾的修改后的哈希。HMAC 专门设计用于解决此问题，通过在嵌套散列操作中多次将密钥与消息组合，导致无法轻易执行长度扩展的摘要。