令牌化算法原理：随机生成、哈希、加密，选哪个？

这一章咱们聊聊三种核心令牌化算法的取舍。我见过不少团队在选型时直接拍脑袋，结果上线后踩坑不断。说实话，没有银弹——每种方案都有自己的脾气。

在展开之前，先明确一个前提：令牌化不是加密，它的核心目标是替代原始敏感数据，让令牌本身没有业务价值或很难还原出原文。基于这个目标，三种主流算法走上了不同的路。

随机生成令牌

这是最直观的做法。从令牌空间里随机挑一个值，跟原始数据建立映射关系，存在一个查找表里。说白了就是「发一个号，记一笔账」。

优点：

  • 不可逆性最强：令牌本身不含原始数据的任何数学关系，就算拿到全量令牌，也推算不出原文。
  • 性能极高：生成就是一个随机数+去重查询，延迟通常在微秒级。
  • 令牌长度可控：可以按需设定格式，比如固定12位数字、大写字母组合等。

缺点：

  • 必须维护映射表：表一旦丢了，所有令牌都变废纸。这是最大的运维风险。
  • 空间膨胀：每生成一个令牌就要存一条记录，10亿条数据就是10亿行。
  • 不可用于分段或范围查询：令牌之间没有顺序关系，你没法对令牌做「大于」「区间」操作。

我曾经遇到过的一个坑：某支付系统用随机令牌存信用卡号，映射表只做了单节点Redis。某次redis宕机重启后数据没持久化…嗯，那一夜全团队都在从头重建映射。后来加了AOF+RDB双保险，但心理阴影至今未消。

哈希令牌

用SHA-256等哈希函数直接对原始数据取摘要，输出作为令牌。不存映射表，每次重新计算即可。听起来很完美？事情没那么简单。

优点：

  • 无状态、零存储：不需要数据库，节省大量存储和维护成本。
  • 确定性：同样的输入永远输出同样的令牌，便于数据去重和关联分析。

缺点：

  • 可被彩虹表攻击：如果原始数据空间不大（比如手机号、身份证号），预计算所有哈希值并不难。
  • 无法反向还原：注意，这不是缺点，而是特性。但业务上有时需要从令牌找回原文，哈希做不到。
  • 输出长度固定：256位哈希值太长（64个十六进制字符），有些场景存不下或传输带宽不够。

我的习惯做法：对抗彩虹表，一定要加盐（salt）。而且每个应用用不同的静态盐，如果对安全性要求更高，可以每笔数据再加一个随机动态盐。

加密令牌

用AES等对称加密算法对原始数据加密，输出密文作为令牌。密钥由自己保管，可以解密还原。

优点：

  • 可还原：唯一一种能在不依赖外部映射表的情况下，从令牌逆推回原文的方案。
  • 长度紧凑：经过base64编码后，长度相对可控。比如AES-128加密16字节明文，输出32字符。
  • 标准化强：全球通用的算法，经过NIST等权威机构验证，安全性有保障。

缺点：

  • 密钥管理是双刃剑：密钥泄露=全量令牌可被解密，密钥轮换需要重加密所有已有令牌。
  • 确定性加密有风险：ECB模式或固定IV的CBC模式，相同明文会生成相同密文，容易做频率分析。必须用随机IV+GCM模式。
  • 性能中等：加密/解密操作比随机生成慢1-2个数量级，但通常还在可接受范围（毫秒级）。

注意：加密令牌本质上是「可逆令牌化」。如果你的合规要求是令牌必须彻底不可逆（比如PCI DSS在某些语境下的解读），加密方案可能不满足。选型前务必跟法务和合规确认清楚。

一图看清三种方案的对决

下面这张图是我自己平时培训时画的，把核心比较维度列出来了。你仔细看看，选型时就有谱了。

令牌化三种算法核心对比架构 随机生成 哈希令牌 加密令牌 需要映射表 存储量大 运维风险高 无状态 零存储 纯计算 依赖密钥 密钥管理是命门 ❌ 不可逆 ❌ 不可逆（单向） ✅ 可逆（有密钥） 抗彩虹表：强 抗彩虹表：弱（需加盐） 抗彩虹表：强（随机IV） 性能：极高（μs级） 性能：高（μs~ms级） 性能：中等（ms级） 建议：静态数据选随机（强不可逆），去重场景选哈希+盐，需要还原选加密（但必须管好密钥）

一张表搞定选型决策

如果你的项目正在纠结选哪个，直接看这张对比表。我后来做咨询时经常拿它给客户拍板。

维度 随机生成 哈希令牌 加密令牌
可逆性 不可逆 不可逆 可逆（需密钥）
存储需求 必须（映射表） 零存储 零存储
抗彩虹表 天然强 弱，必须加盐 强（随机IV）
性能 极高 高 中等
支持去重 否（每次不同令牌） 是（确定哈希） 是（但需相同IV）
令牌长度 自定义（如12位） 固定（如64 hex） 固定（≈1.3×原文）
运维复杂度 高（要备份映射表） 低（无状态） 中（密钥管理）
合规友好度 高（彻底不可逆） 中（加盐后可接受） 低（可逆，需特殊说明）

代码示例：三种方案的极简实现

光说不练假把式。下面我用Python写一个最简版的三种算法骨架。你拿来改吧改吧就能用。

import secrets, hashlib, os
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend

# ---------- 1. 随机生成令牌 ----------
def random_(length=12):
    """生成随机数字字母组合令牌，需要配合映射表使用"""
    chars = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'  # 去掉易混淆字符
    return ''.join(secrets.choice(chars) for _ in range(length))

# ---------- 2. 哈希令牌 ----------
SALT = b'static-salt-for-this-app'  # 静态盐，不可泄露

def hash_(data: str) -> str:
    """SHA-256哈希，加静态盐"""
    sha = hashlib.sha256()
    sha.update(SALT)
    sha.update(data.encode('utf-8'))
    return sha.hexdigest()

# ---------- 3. 加密令牌 ----------
AES_KEY = os.urandom(32)  # 实际生产中从密钥管理系统获取

def encrypt_(data: str) -> bytes:
    """AES-256 GCM加密，输出IV+密文+tag"""
    iv = os.urandom(12)  # GCM推荐96位IV
    cipher = Cipher(algorithms.AES(AES_KEY), modes.GCM(iv), backend=default_backend())
    encryptor = cipher.encryptor()
    ct = encryptor.update(data.encode('utf-8')) + encryptor.finalize()
    # 返回 IV + 密文 + GCM tag
    return iv + ct + encryptor.tag

def decrypt_(: bytes) -> str:
    """从加密令牌还原原始数据"""
    iv = [:12]
    tag = [-16:]
    ct = [12:-16]
    cipher = Cipher(algorithms.AES(AES_KEY), modes.GCM(iv, tag), backend=default_backend())
    decryptor = cipher.decryptor()
    plain = decryptor.update(ct) + decryptor.finalize()
    return plain.decode('utf-8')

个人提醒：上面哈希令牌的代码用了静态盐，生产环境最好用应用级+记录级双盐。加密令牌的密钥绝不能写死在代码里——我习惯用HashiCorp Vault或AWS KMS去取。

一个真实的选型案例

我之前帮一家电商做数据脱敏。他们的需求是：对用户手机号做令牌化，但要在退款时能查到原始手机号联系用户。你想想看，随机令牌虽然安全，但退款场景不支持；哈希令牌不能还原；加密令牌完美符合——密钥放HSM里，只有退款服务在指定时段才能调解密接口。

后来生产上线，加密性能在2000 QPS下平均耗时2.3ms，完全够用。密钥轮换时花了点功夫，但整体没出过安全事故。

关键复盘：加密令牌很适合「既要脱敏又要偶尔还原」的场景。但一定要做密钥轮换演练，确保流程走得通。否则轮换那天发现解密脚本跑不通…那酸爽，你懂的。

小结一下

三种算法各有胜负，没有谁好。我的建议是：

  1. 如果业务完全不需要还原，而且你能运维好映射表——选随机生成，安全上限最高。
  2. 如果需要去重、关联分析，且原始数据空间有限（如邮箱、手机号）——选哈希+动态盐，零存储很香。
  3. 如果业务需要可逆还原，比如风控、客服——选加密令牌，但务必做好密钥治理。

嗯，选型这事，说到底是对业务场景和运维能力的综合评估。别被技术光环迷了眼。

← 上一章 📖 返回目录 下一章 →