mac和hmac_HMAC和MAC解释：如何使用JWT建立安全认证

mac和hmac

HMAC和MAC是身份验证代码，通常是JWT身份验证系统的骨干。 让我们看看它们是如何工作的！

MAC- 消息验证码

MAC就像它们听起来一样。 小代码，使消息的接收者可以知道谁是发送者（身份验证）。 通过使用消息和密钥作为输入来计算MAC代码。 拥有该密钥副本的任何人都可以验证该代码和消息是否由具有相同密钥的人创建。

实现此目标的一种方法是使用哈希函数，例如SHA-256。 简而言之，哈希函数接受输入，然后返回输出，其中：

• 不同输入的输出不太可能相同
• 对于相同的输入，输出始终相同
• 输出是不可预测的-以任何方式更改输入都会导致输出看似随机变化

鉴于此，发送方生成MAC的简单例子可能是：

macCode = sha256('thisIsASecretKey1234' + 'my message here' )

然后，接收方的验证将是：

macCode == sha256( 'thisIsASecretKey1234' + 'my message here' )

请注意，MAC不一定使用哈希函数，但是哈希可以用作“签名”机制。 如需进一步阅读，请参阅MAC Wikipedia文章 。

HMAC- 基于哈希的消息身份验证代码

HMAC是一种MAC。 所有HMAC都是MAC，但并非所有MAC都是HMAC。 主要区别在于，HMAC使用两轮散列而不是一轮（或不进行）。 每一轮哈希使用一部分秘密密钥。 举一个朴素的例子：

sha256 ( 'thisIsASe' + sha256 ( 'cretKey1234' + 'my message here' ))

这是RFC-2104中提供的功能的简化版本。

为什么要使用HMAC？ 为什么我们需要哈希两次？

使用许多哈希函数，更改消息（不知道密钥）并获得另一个有效的MAC相对容易。 我们称此为长度扩展攻击 。 没有针对当前HMAC规范的已知扩展攻击。

要进一步了解HMAC，请在这里查看 。

具有JWT的HMAC

如果您曾经在Web应用程序上使用过JWT进行身份验证方案，那么您就会知道JWT对于跟踪谁是谁非常有用。 JWT（使用HMAC作为签名方案时）基本上只是HMAC消息，其中消息数据是JSON对象。

关于JWT系统，有趣的是JWT的发送者和接收者通常是同一实体，即Web服务器。 看下面的例子：

• 用户为服务器提供用户名和密码
• 服务器验证用户名和密码正确
• 服务器使用HMAC生成JWT：

hmacCode = sha256 ( 'thisIsASe' + sha256 ( 'cretKey1234' + '{"email":"lane@qvault.io"}' ))

• 服务器使用以下（解码的）JWT进行响应：

header .{ "email" : "lane@qvault.io" }.hmacCode

• 用户决定通过发送以下请求来更新他/她的个人资料图片：

PUT /users/profile_picture
Authentication: Bearerheader .{ "email" : "lane@qvault.io" } .hmacCode

{ "new_picture" : "http://linktopicture.com/mypic" }

• 服务器解析JWT。 JWT说用户是“ lane@qvault.io”
• 服务器通过验证HMAC代码来验证用户确实是Lane，因为只有有权访问密钥“ thisIsASecretKey1234”的人才能制作与“ lane@qvault.io”消息相对应的HMAC代码。
• 如果验证成功，则服务器将更新Lane的个人资料图片

因为这是JWT工作原理的非常基本的示例，所以它跳过了一些实现细节。 但是，如果您想了解更多详细信息，请查看jwt.io上的说明。

如果您觉得我错过了重要的事情或有任何疑问，请随时在Twitter上与我联系！

• Twitter上的车道： @wagslane
• Dev.to上的车道： wagslane

先前发布在 https://qvault.io/2019/12/12/hmac-and-mac-explained-simply-building-secure-auth-with-jwts/

翻译自: https://hackernoon.com/hmac-and-mac-explained-how-to-build-secure-authentication-with-jwts-jc8b3ylb

mac和hmac