动态口令、JWT 签名与 CSP：三个安全工具的实操

两步验证的六位数字每 30 秒变一次、登录后拿到的令牌是一长串点号分隔的字符、安全扫描报告里总提 Content-Security-Policy——这三样都是开发者和运维绕不开的日常。它们的共同点是：原理不复杂，但手算和手写极易出错。

一、TOTP：时间换出来的六位数字

TOTP（基于时间的一次性口令，RFC 6238）的核心公式是：把当前 Unix 时间除以周期（通常 30 秒）取整得到计数器，用共享密钥（Base32 编码）对这个计数器做 HMAC-SHA1，再截取成 6 位数字。所以：

双方不用通信，只要密钥相同、时钟基本同步，算出来的码就一致；
误差来自时钟：手机和服务器差几十秒就会验证失败，这是最常见的「码明明对却报错」原因；
参数要对齐：位数（6/8 位）、周期（30/60 秒）、哈希（SHA1/SHA256/SHA512）三项必须和服务端完全一致。

生成工具支持这些参数组合并附倒计时进度，联调时用来核对服务端实现是否正确特别方便。密钥等同于密码：只在本地计算、不要贴进聊天记录或在线表单。

二、JWT 签名：三段结构与 HMAC

JWT 形如 header.payload.signature，前两段是 Base64URL 编码的 JSON，第三段是签名。以 HS256 为例：

Header 声明算法与类型，如 {"alg":"HS256","typ":"JWT"}；
Payload 放业务声明，常用 sub、iat、exp（过期时间，Unix 秒）；
签名 = HMAC-SHA256(base64url(header) + "." + base64url(payload), 密钥)，再做 Base64URL。

HS256/HS384/HS512 只是哈希长度不同，共用同一个密钥——对称签名意味着能验签的人也能签，所以密钥绝不能下发到前端。生成器适合本地联调、验证算法实现和构造测试用例；已有令牌要读懂内容，用 JWT 解析指南里配套的解析器。

三、CSP：给浏览器划出白名单

Content-Security-Policy 是一个响应头，告诉浏览器「哪些来源的脚本、样式、图片可以加载」。一条典型策略：

default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'

写 CSP 最常踩的三类坑，工具会主动提示：

风险写法	问题
`'unsafe-inline'`	允许内联脚本，基本等于放弃了防 XSS 的初衷
通配域名 `*`	白名单过宽，任何子域都能注入
缺 `object-src`	老式插件入口没堵住，是常见扫描扣分项

生成器可可视化编辑指令、直接产出响应头，也能粘贴现有 header 反向解析回填。上线前建议先用 Content-Security-Policy-Report-Only 观察一段时间，再切到强制模式。

四、常见问题

问：TOTP 验证码对不上，先查什么？
按优先级：设备时间是否自动同步、密钥是否多贴了空格、位数/周期/哈希三项参数是否与服务端一致。

问：JWT 的 Payload 是加密的吗？
不是，只是 Base64URL 编码，任何人都能解出内容。签名的作用是防篡改，不是防读取——别把密码、身份证号放进 Payload。

问：这些工具会保存我输入的密钥吗？
不会。本站工具在浏览器本地用 WebCrypto 计算，密钥不上传、不存储。但生产密钥仍建议只在离线环境使用。

🔑 TOTP 动态口令生成器：Base32 密钥生成 6/8 位动态码，支持 30/60 秒周期与 SHA1/SHA256/SHA512，附倒计时；JWT 生成器：编辑 Header/Payload 用 HS256/HS384/HS512 本地签名，分段展示便于核对；CSP 生成器：可视化编辑指令、反向解析现有 header，并提示 unsafe-inline、通配符与缺失 object-src 等风险。

五、一条自查清单

两步验证联调失败 → 先校时，再核参数；
构造测试令牌 → 明确 exp，密钥只放服务端；
配置 CSP → 先 Report-Only 观察，收紧后再强制；
任何含真实密钥的调试 → 用完即弃，别留在浏览器历史里。

安全工具的价值在于「把看不见的计算变得可核对」。理解公式、对齐参数、管好密钥，这三件事做好，日常的安全联调就不会再靠猜。