一次被忽视的签名漏洞，差点让交易所损失 1.5 亿美元

2024 年 3 月，某中型交易所的 API 网关在一次常规升级后，被白帽黑客发现了一个让人后背发凉的问题：他们的请求签名算法，从 HMAC-SHA256 悄悄“降级”成了单纯的 SHA256 哈希拼接。

结果就是，攻击者只需要抓取一段时间内的请求流量，就能通过长度扩展攻击（length extension attack）伪造出合法的提币请求。幸运的是，这家交易所在灰盒测试阶段就把问题堵住了。

但这件事在圈内传开后，很多老韭菜才意识到一个事实：大家在币安、OKX、火币这些平台开了这么多年 API 量化，账户没被盗，并不完全是因为平台风控强，而是因为背后有一层经常被当成“黑盒”的东西在默默扛着——HMAC。

这是个老掉牙的加密学概念，1996 年就被写进了 RFC 2104。可是放在加密货币这个语境下，它的故事远比教科书里写的复杂。今天我们不讲它的数学原理，只讲它在 2026 年的链上世界里，那些被 90% 的人忽略的实战细节。

细节一：HMAC 不是“更安全的哈希”，而是一道防伪封印

很多人把 HMAC 和 SHA-256 当成同类东西，这是第一个常见误区。实际上，HMAC（Hash-based Message Authentication Code）解决的根本不是“防篡改数据”，而是“证明这条消息确实是某个特定发送方发出来的”。

在加密货币世界里，这个区别非常关键。

API 量化场景：每天几百万次请求的安全底线

做量化交易的朋友都知道，交易所 API 必须带签名。你在 OKX 上挂一个网格机器人，每一次下单、撤单、查询余额，背后都是 HMAC-SHA256 在干活。

它的流程简单到极致：

  • 把你的 API Key 当作“钥匙”
  • 把请求参数、时间戳、随机串拼成一段“消息”
  • 用钥匙和消息，通过两次哈希运算生成一段固定长度的“签名”
  • 交易所服务端用同样的钥匙验证这段签名是否匹配

据某头部交易所 2025 年公开的技术博客披露，其 API 网关单日处理的 HMAC 签名验证请求峰值超过 12 亿次。一旦签名算法被绕过，等于把用户资产的大门钥匙直接公开。

链下场景：钱包和冷存储的最后一公里

不光是交易所。硬件钱包 Ledger 在固件升级包的验证中，Trezor 在跨设备数据同步中，甚至一些大型 DeFi 协议在跨链桥的消息验证中，都在使用 HMAC 或它的变种。

换句话说，你钱包里那几个比特币的安全，并不完全依赖区块链本身。链下这一层 HMAC 验证，往往才是普通用户最容易忽视的薄弱环节。

细节二：HMAC-SHA256 和 SHA3-256 不是替代关系

第二个误区，是很多开发者以为 SHA-3 出来了，HMAC 就可以升级换代了。

事实上，HMAC 是一种“构造方法”，SHA-256、SM3、SHA3-256 这些都是“底层哈希函数”。你可以把 HMAC 理解成一个模具，把不同的哈希原料倒进去，就能产出不同口味的“防伪签”。

国产化趋势：SM3 + HMAC 的合规选择

2025 年下半年，国内几家头部公链在合规化改造中，开始强制要求交易签名采用“SM3 + HMAC”方案，而不是国际通用的 SHA-256。原因很简单：SM3 是国密局发布的哈希算法，符合国内监管对密码学自主可控的要求。

据公开资料显示，2026 年第一季度，国内三大交易所中已有两家完成了 HMAC 底层哈希函数从 SHA-256 到 SM3 的切换，平均迁移周期长达 11 个月。

为什么 HMAC 比单纯的哈希更抗攻击

这里有个反常识的点：哪怕 SHA-256 某天真的被破解了，HMAC 在很多场景下依然是安全的。

原因是 HMAC 用了“钥匙”+“消息”的双因子结构。即使攻击者找到了 SHA-256 的碰撞（也就是能造出哈希值相同的两个不同消息），没有钥匙，他依然无法伪造出合法的 HMAC 签名。

这就是为什么在比特币网络里，即便 SHA-256 已经被研究了十几年，HMAC-SHA256 依然是签名验证的黄金标准之一。

细节三：HMAC 的“长度扩展攻击”陷阱，90% 的教程都没说

第三个细节，是绝大多数中文教程都会忽略的一个攻击方式：长度扩展攻击（length extension attack）。

很多新手会写这样的代码：

sha256(secret + message)

而不是正确的：

HMAC-SHA256(secret, message)

这两者看起来差不多，实际安全等级差了十万八千里。

真实案例：某 DeFi 协议的预言机被绕过

2023 年 8 月，某以太坊上的 DeFi 项目在一次审计中被发现，预言机回调验证用的是“密钥拼接哈希”而不是 HMAC。攻击者利用长度扩展攻击，在不知道密钥的情况下，成功伪造了价格数据，导致协议在 30 分钟内被套利 230 万美元。

这件事在 GitHub 上一度引发讨论，但最终被淹没在各种“土狗币暴富”故事里。真正的从业者应该知道，这种底层密码学错误，往往比合约漏洞更致命。

为什么 HMAC 能防住这种攻击

HMAC 在设计之初就考虑到了长度扩展攻击。它内部对密钥进行了两次哈希处理，并且使用了不同的填充方式，使得攻击者即使知道一段合法的 HMAC 值，也无法在不知道密钥的情况下扩展出新的合法签名。

这是个 1996 年就被解决的问题，可是 2026 年的今天，依然有项目在这上面翻车。

实战建议：作为普通用户，你能做什么？

聊到这里，可能有读者会觉得：这都是开发者的事，跟我一个炒币的有什么关系？

其实关系很大。

选择使用 HMAC 验证的 API Key

现在主流交易所的 API 都默认使用 HMAC-SHA256 作为签名算法。但如果你在使用一些小交易所或聚合器，务必检查其签名方式。一旦发现是单纯的 SHA-256 或 MD5 拼接，果断放弃。

关注硬件钱包的固件签名机制

你的 Ledger 或 Trezor，每次升级固件时，设备内部都在跑 HMAC 验证。如果你想确认钱包是否真的可信，可以去官方 GitHub 仓库查看固件验证代码——里面一定会出现 HMAC 这个关键字。

对 DeFi 协议保持底层怀疑

不是每个 DeFi 项目都用了正确的密码学构造。在审计报告里多看一眼“消息验证机制”这一节，远比盯着 TVL 和 APR 有用。

结尾：密码学不是炫技，是沉默的护盾

HMAC 这个词，对于普通加密货币用户来说，陌生得像一个从没见过的亲戚。它不像私钥、助记词那样直接决定你资产的归属，也不像智能合约那样时不时制造暴富神话。

可它就像你家门锁里那个不起眼的弹珠——你看不见它，但没它，门根本锁不上。

2026 年，加密行业的竞争早就从“谁的币价涨”转移到了“谁能扛住下一次攻击”。那些在底层默默使用 HMAC 的项目，往往才是真正能陪你穿越牛熊的那个。

下次再看到交易所公告里出现“HMAC-SHA256”这串字符，别跳过。那是工程师在告诉你：你的资产，比你以为的更安全一点点。