使用 HMAC 散列密码和签名有什么安全优势吗？答案

【问题标题】：Hashing passwords and signature with HMAC any security advantages?使用 HMAC 散列密码和签名有什么安全优势吗？
【发布时间】：2017-10-04 04:08:29
【问题描述】：

我对使用盐对密码进行哈希处理以及使用 HMAC 密码或用作签名等方式感到有些困惑。我已经阅读了很多关于它的文章，但似乎我没有使用这个或那个的意义。

我得到了使用这种方式的这个例子（用数字标记的问题）：

散列密码

来自用户的密码使用 SHA-256 和存储在数据库中的每个用户的唯一盐进行哈希处理。密码和盐只是像这样hash(key + password) 连接并运行多轮散列。

哈希用户密码的更好方法似乎是 HMAC。在这种情况下使用hmac-sha256(password, salt)。

有人说使用盐作为 HMAC 的密码是没有意义的但是盐对用户来说是不可见的，因为它只是被存储了在数据库中。对我来说，它只不过是一个密码。

对于 API，所有用户都会获得一个唯一且随机的 api_key 和一个 api_secret。 api_key 由标头在所有请求中发送以识别用户。那应该是一种“无状态认证”。

api_secret 将在后端使用hmac-sha256((api_key + nonce), api_secret) 生成signature。

nonce 是一个随机值，它以纯文本形式在另一个标头中发送，同时也是一个散列值，用于验证 nonce 本身不会被操纵（实际上并不需要，因为它会改变整个signature)...所以一种随机签名：

rand = random();
hash = hmac-sha256(rand, api_secret);
nonce = rand + "-" + hash;

我很难理解创建安全哈希的或多或少安全的方法是什么。有些人说“好吧，这是安全的......你应该这样做”，然后其他人说“哦，你忘记了这个或那个攻击或易受攻击”。所以我试着用一种简单的“我是傻瓜”来理解如何以及为什么。

【问题讨论】：

【解决方案1】：

SHA-256 不是一个很好的散列方法。使用 bcrypt、PBKDF2 或 scrypt。

Peppering（HMAC-ing 密码）如果您认为自己有可能在路上遇到 SQL 注入漏洞，并且应用服务器漏洞的可能性较低。

正确的 Peppering 意味着您的应用程序服务器持有密钥并且它未存储在您的数据库中。

如果您在路上不小心进行了 SQL 注入，黑客可能会窃取您所有的密码，但无法窃取密钥

听起来您要对每个请求进行哈希处理，这会非常缓慢。你应该散列一次并提供一个令牌

【讨论】：

使用 bcrypt 代替多轮 SHA-256 散列有什么好处？两者都应该很慢不是吗？同时使用胡椒和盐应该没问题（代码中包含盐和胡椒的数据库）。我正在对每个请求进行哈希处理，以使可能的暴力攻击变慢。在正常请求中没有明显的减慢。
"在正常的请求中没有明显的减速"，嗯，但应该有。 SHA256 在 GPU 上可以轻松破解，而 bcrypt 则不然。你想要你能找到的最慢的哈希