令牌化原理

说到令牌化，很多人第一反应是“不就是加密吗？”
嗯，还真不是。我刚开始接触时也这么想，后来被一个安全事故狠狠教训了一课。
令牌化的核心是替换——用一段无意义的令牌替代敏感数据，比如把信用卡号变成一串随机字符。
而加密是变换——数据还在，只是你看不懂。

令牌化与加密的区别

为什么我们要用令牌化而不是加密？
我个人习惯用一张表来对比，这样最直观。

维度	令牌化	加密
数据是否保留	原始数据被移除，仅存令牌	原始数据以密文形式存在
可逆性	依赖安全令牌库的映射关系	依赖密钥，数学可逆
合规风险	令牌无明文特征，PCI DSS等标准通常认为脱敏	密文仍属于敏感数据，密钥管理复杂
性能开销	每次查库，延迟取决于存储和网络	CPU密集型，但可硬件加速
典型场景	支付卡号、社保号、手机号	文件加密、传输加密、静态存储

举个例子：假设你存了用户的信用卡号 4111 1111 1111 1111。
加密后它变成 3A4C...89F2，虽然乱码但长度不变，攻击者拿到密文后可以尝试暴力破解密钥。
令牌化后它变成 tok_8f3a2b，你根本不知道原始号码是否还是16位数字。
我在项目中遇到过客户要求同时保留两种方案：核心支付用令牌化，日志备份用加密。结果日志泄露时，密文被用弱口令解了……从那以后，我强烈建议：敏感数据能不用密文就别用。

令牌生成算法

令牌的核心在于生成算法。算法决定了令牌的安全性、唯一性和可追溯性。
常见的分为三类，我按实战比例排列：

1. 随机生成 – 最常用，完全无规律。比如UUIDv4或urandom取的字节然后编码。
2. 哈希生成 – 对原始数据加盐后哈希，输出截断作为令牌。好处是无状态，坏处是碰撞风险。
3. HMAC生成 – 带密钥的哈希，防伪造。适合需要验证令牌来源的场景。

下面是每种算法的伪代码，我在实际产品里几乎都跑过：

// 随机生成（Python）
import os, base64
def random_(length=16):
    return base64.urlsafe_b64encode(os.urandom(length)).decode()[:length]

// 哈希生成（SHA-256加盐）
import hashlib
def hash_(data, salt):
    return hashlib.sha256((data + salt).encode()).hexdigest()[:16]

// HMAC生成
import hmac
def hmac_(data, key):
    return hmac.new(key.encode(), data.encode(), 'sha256').hexdigest()[:16]

这三种算法在实际中怎么选？看需求：

• 需要高性能、无状态 → 哈希或HMAC
• 需要完全随机、不可预测 → 随机生成
• 需要验证令牌来源（比如API令牌） → HMAC

说白了，随机生成最安全，但也最贵（要存储映射表）。
哈希和HMAC省去了存储，但要注意碰撞和重放攻击。我个人偏好HMAC，因为密钥可控，而且可以版本升级。

令牌格式

令牌的格式决定了它的可读性和兼容性。常见的格式有以下几种：

属性	推荐值	理由
长度	16~32字节	太短易碰撞，太长浪费存储
字符集	URL-safe Base64（a-z A-Z 0-9 - _）	避免URL、JSON中的转义问题
前缀	可选，如 tok_	方便区分令牌类型
校验位	可选，如上BCH码	防手误输入错误

我记得有次看到同事写的令牌只用了A-F0-9（十六进制），结果长度暴增，数据库字段都不够用。
嗯，这里要注意：令牌不是给人看的，是给机器用的。所以字符集越紧凑越好。
推荐使用URL安全的Base64编码，去掉=填充，长度正好是字节数的4/3。