HMAC 生成器

HMAC 是大多数带签名的Webhook、AWS Signature v4头部信息以及 JWT HS256令牌背后的算法。输入消息和密钥,选择哈希函数族后,该生成器即可按照RFC 2104标准精确生成 HMAC,适用于验证后端即将发送的数据,或复现从API接收到的签名。

如何计算 HMAC

  1. 1

    粘贴消息

    需要签名的具体字节数,可以是Webhook有效载荷、标准请求数据或任意字符串。

  2. 2

    输入密钥

    可为文本或十六进制值。该生成器会根据RFC标准将其转换为符合块大小要求的哈希值。

  3. 3

    选择哈希算法

    默认使用SHA-256;如需兼容旧版本,请选择SHA-1、SHA-384、SHA-512或MD5。

  4. 4

    复制签名

    输出为小写十六进制格式,可直接粘贴到Webhook配置或授权头(Authorization header)中。

HMAC 的内部原理

HMAC 将简单的哈希函数封装为带密钥的构造形式,从而防止在没有密钥的情况下伪造签名。

RFC 2104 算法

HMAC(k, m) = H((k' ⊕ opad) ∥ H((k' ⊕ ipad) ∥ m))

其中 k' 是填充到哈希块大小的密钥,opad = 0x5c repeatedipad = 0x36 repeated 为填充常量。

算法选择

算法 块大小 输出长度 适用场景
HMAC-SHA-256 64 字节 32 字节 现代默认值,用于 Webhook 签名
HMAC-SHA-384 128 字节 48 字节 高安全性 API 签名
HMAC-SHA-512 128 字节 64 字节 长期有效令牌
HMAC-SHA-1 64 字节 20 字节 传统版本(AWS S3 v2、OAuth 1.0)
HMAC-MD5 64 字节 16 字节 仅适用于旧版本;新项目请勿使用

HMAC 出现的位置

  • GitHub、Stripe、Shopify 的 Webhook:头部为 X-Hub-Signature-256Stripe-Signature 等。
  • AWS Signature v4:对规范请求执行的一连串 HMAC-SHA256 运算。
  • JWT HS256:令牌签名为 HMAC-SHA-256(header.payload, secret)
  • 密码重置令牌:由用户 ID、有效期及站点密钥组合生成的 HMAC。

常见错误

  • 将十六进制编码的密钥直接作为文本传递,而非先将其解码为字节。
  • 对错误的载荷字节进行签名:部分 Webhook 会对包含空白字符的原始请求体进行签名,而其他 Webhook 则采用规范格式进行签名。
  • 在 JavaScript 或 Python 中使用 == 比较签名;务必采用时间安全(timing-safe)的比较方式以抵御时序攻击。

常见问题

几乎总是因为消息字节存在差异。对 JSON 解析后的请求体进行签名会引入空白字符变化;应直接对原始请求体进行签名。同时需确保双方对密钥的解码方式一致(均采用十六进制或原始字节格式)。

是的。如果密钥长度小于哈希块大小,则会进行零填充;若长度较长,则先进行哈希处理。RFC 2104建议密钥长度至少与输出长度相同(SHA-256为32字节)。

HMAC 仍能抵御已知的 MD5 碰撞攻击,因为该攻击无法影响 HMAC 的构建过程。不过,对于所有新代码都应使用 HMAC-SHA-256,开发工具和审计人员均对此有明确要求。

会。为了计算 HMAC,消息和密钥会通过加密的 HTTPS 连接发送到我们的服务器。它们仅用于计算,不会被存储或记录。

相关工具

此工具还提供其他语言版本