piapia123
zh

Cookie 签名与验签

编码

所有处理都在浏览器本地完成,数据不上传服务器

输入
把文件拖到这里可直接载入
输出

签名 cookie 防的是篡改而不是偷看:值仍以明文存在浏览器里,但只有知道密钥的服务端能算出匹配的 HMAC。输出是 Express `cookie-signature` 的形态 `s:<base64url(值)>.<base64url(HMAC)>`,HMAC 算的是原始值(UTF-8 字节)。验签时会先按你选的算法验,不通过再试另外三种 —— 如果能对上就告诉你「算法选错了」而不是笼统的「签名不对」。比较用逐字节定长比较,不短路。全部计算在浏览器本地完成,不上传密钥。

功能

  • 四种 HMAC:SHA-256 / SHA-384 / SHA-512 / SHA-1
  • 输出 Express `cookie-signature` 的 `s:` 形态
  • 同时给出十六进制签名,便于与 `openssl dgst -hmac` 对照
  • 验签能区分「格式错」「密钥/值错」「算法选错」三种原因
  • 算法选错时直接报出签名真正用的算法
  • 定长逐字节比较,避免时序侧信道
  • 空密钥直接报错,不让一个「看着正常」的假签名流出去
  • 每行可单独复制,也可复制全部

使用方法

  1. 选择签名或验签
  2. 填好密钥,选择算法
  3. 签名时输入 cookie 值;验签时输入整条 `s:...`
  4. 结果即时给出,含拆解与 openssl 对照命令

常见问题

签名会把 cookie 内容藏起来吗?
不会。签名只保证「没被改过」,值本身还是明文,用户和中间人照样能读到。要保密得用 HTTPS,并且不要把秘密直接放进 cookie。签名解决的是「用户把 user=alice 改成 user=admin」这类伪造。
为什么不能直接用 `===` 比较签名?
`===` 在发现第一个不同的字节时就返回,于是「猜对前几个字节」比「完全猜错」慢那么一点点。攻击者可以统计大量请求的时间差,一个字节一个字节地把签名凑出来。所以这里用逐字节异或累加、不短路的定长比较。
密钥该怎么保存?
密钥是这套签名的全部安全性所在,必须只放在服务端,并且足够长、随机。别写进前端代码,也别和 cookie 一起发出去。这个工具不会保存你输入的密钥,但页面是网页 —— 生产密钥请用你自己机器上的命令处理。

相关工具