← 返回工具箱

SECURITY / MESSAGE AUTHENTICATION

HMAC 签名 / 验签工具

明确消息与 Secret 的原始字节，再使用 Web Crypto 生成或验证 HMAC。适合复现 Webhook、API 回调、对象存储和旧系统签名问题。

请只使用测试密钥：计算完全在当前浏览器完成，但生产 Secret 仍不该出现在网页、剪贴板历史、截图或工单里。HMAC 用于认证与完整性，不是加密，消息内容不会被隐藏。

当前密钥为 24 bit。正式密钥建议至少达到 256 bit，并由安全随机源生成。

原始消息

签名比较的是字节；换行、空格和编码不同都会改变结果。

先确认原始字节

上游若写“Base64 Secret”，通常是先解码再做 HMAC；把那串字符当 UTF-8 文本会得到完全不同的签名。

再确认签名原文

Webhook 常要求签 timestamp + “.” + raw body。不要先解析 JSON 再重新序列化，否则空格与字段顺序可能改变。

最后确认比较方式

本页交给 Web Crypto 验签。生产服务还要校验时间戳、重放窗口、事件 ID 和密钥轮换，不能只比较一个字符串。

RELATED TOOLS

接着处理

查看全部工具 →
Hash 计算计算普通摘要与文件 Hash，区分 Hash 和带密钥 HMAC。JWT 签名 / 验证使用 HMAC 生成和验证 HS256、HS384、HS512 JWT。Base64 编解码检查文本、文件与 Base64 字节是否与上游一致。Basic Auth生成或解析 Authorization: Basic 请求头。

USE & REVIEW

HMAC 签名 / 验签工具常见问题

查看全部工具指南 →

HMAC 和普通 SHA-256 Hash 有什么区别？

普通 Hash 只依赖消息，任何拿到消息的人都能计算同样的摘要；HMAC 还需要双方共享的 Secret，用来验证消息来自持有密钥的一方且没有被修改。HMAC 仍不会隐藏消息内容，因此不能替代 AES 等加密。

为什么同一个 Secret 看起来一样，签名却不同？

签名使用的是字节，不是输入框里看起来相同的字符。比如 c2VjcmV0 按 UTF-8 是 8 个字符，按 Base64 解码则是 secret 六个字节。消息里的换行、空格、JSON 字段顺序和结尾换行也会改变结果，必须按上游文档还原原始字节。

Webhook 验签应该使用解析后的 JSON 还是原始请求体？

多数 Webhook 要求签原始请求体，有些还会在前面拼接时间戳、事件 ID 或版本号。解析 JSON 后再 stringify 可能改变空格、转义和字段顺序，从而导致签名不一致。服务端应先保存 raw body，再按供应商规定拼出准确的签名原文。

可以直接粘贴 sha256= 开头的签名吗？

可以。页面会识别 sha256=、hmac-sha256= 等常见算法前缀并只解码后面的签名字节。如果前缀声明 SHA-256，而下拉框选了 SHA-512，工具会明确拒绝，避免在算法不一致时继续做一个误导性的比较。

HMAC-SHA1 还能使用吗？

页面保留 SHA1 是为了复现旧接口和兼容历史系统。新协议通常优先使用 HMAC-SHA256 或更强算法，并使用足够长的随机密钥。即使 HMAC-SHA1 不等同于普通 SHA-1 碰撞问题，也不值得在没有兼容要求的新设计里继续增加技术债。

Secret、消息和文件会上传服务器吗？

不会。文本解码、文件读取、HMAC 生成、SubtleCrypto.verify 和报告下载都在当前浏览器完成。下载报告会省略 Secret，但生产密钥仍可能被浏览器扩展、剪贴板历史、截图和屏幕共享接触，最稳妥的做法是只使用测试密钥。