hmac不适合直接用于密码存储，因其是快速、无迭代、无内置盐管理的消息认证码，无法抵御暴力破解；正确做法是使用pbkdf2_hmac、bcrypt等专用密钥派生函数。
hmac 模块根本不适合直接用于密码存储——这是个常见误解，必须先说清。
如果你在考虑用 hmac 替代 hashlib.pbkdf2_hmac 或 bcrypt 来存密码，那大概率会踩坑。它不是为密码哈希设计的，也没有抗暴力破解能力。
为什么不能用 hmac.new(key, message) 存密码？
因为 hmac 是一个**快速、确定性、无迭代**的消息认证码（MAC），它的目标是验证消息完整性+来源可信，不是拖慢攻击者：
- 计算一次
hmac.sha256只需几纳秒，GPU 每秒可跑上亿次 —— 完全扛不住暴力或字典攻击 - 它不内置盐值管理：你得自己生成、存储、关联
key（即“盐”），而这个key若重复使用或硬编码，就退化成固定盐，失去唯一性 -
hmac的key是保密前提下的共享密钥，但密码场景中“密钥”无法安全保管——用户没输密码前，服务端根本不知道该用哪个key去验签 - 它不提供标准化的序列化格式（比如 salt + hash + rounds），验证逻辑极易出错
pbkdf2_hmac 和 hmac 的关系是什么？
别被名字误导：hashlib.pbkdf2_hmac 是密码学标准（PKCS#5）实现，它内部确实调用了 hmac 作为伪随机函数（PRF），但关键差异在于：
- 强制指定迭代次数（如
100000），大幅增加计算成本 - 要求传入独立、随机、每用户唯一的
salt（不是key） - 输出是定长密钥材料，专为密钥派生/密码哈希优化
- Python 中它是
hashlib的一部分，不是hmac模块的函数
所以你真正该用的是：hashlib.pbkdf2_hmac('sha256', password.encode(), salt, 100000)，而不是 hmac.new(salt, password.encode(), 'sha256')。
MD5 加盐拼接（如 md5(password + salt)）为什么更糟？
这种手写加盐方式比 hmac 还危险，原因很实在：
- 长度扩展攻击风险：MD5 是 Merkle–Damgård 结构，攻击者可能利用
md5(salt + password)的中间状态伪造新哈希 - 盐值位置敏感：如果盐拼在前面（
salt + password），且盐太短（如 4 字节），攻击者可穷举所有盐值组合批量试跑 - 无迭代：和裸 MD5 一样快，彩虹表稍作适配就能复用
- 编码歧义：
password + salt若一个是str一个是bytes，Python 会直接报TypeError，线上环境容易崩
那 hmac 模块到底该用在哪？
它适合需要「密钥参与」且「速度优先」的场景，比如：
- API 请求签名：
hmac.new(api_secret.encode(), request_body, 'sha256').hexdigest() - Webhook 签名校验：比对第三方回调携带的
X-Hub-Signature-256头 - 临时令牌签名（配合过期时间）：如生成带时效的下载链接签名
- 绝不用于密码哈希、JWT 的 HS256 签名也不建议 —— 密钥泄露即全盘崩溃
真正做密码存储时，hmac 只是底层组件，你接触不到；暴露给开发者的，应该是 passlib、bcrypt 或 hashlib.scrypt 这类封装了盐管理、迭代、编码、验证全流程的工具。自己拼 hmac，就像用螺丝刀当手术刀——理论上能动，但没人敢让你主刀。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
