如何在SQL存储过程中利用HASHBYTES进行数据脱敏加密？

HASHBYTES不是脱敏而是哈希计算，不可逆且丢失原始语义；真正脱敏需掩码表达式如LEFT(mobile,3)+'**'+RIGHT(mobile,4)，保留可读性与业务可用性。

HASHBYTES 不是脱敏加密，而是哈希计算

直接用 HASHBYTES 对手机号、身份证号做“脱敏加密”是常见误解。它生成的是不可逆哈希值（如 0x... 二进制），原始数据完全丢失，无法还原——这不符合脱敏定义（脱敏要求可读性+部分隐藏，比如 138****1234）。真正需要的不是哈希，而是掩码表达式或动态字符串处理。

为什么用 HASHBYTES 做脱敏会出问题

典型错误场景：把用户手机号 '13812345678' 传给 HASHBYTES('SHA2_512', @phone)，存下 64 字节二进制，再转成十六进制字符串显示——结果是一串无意义乱码，业务方根本认不出这是谁的号码，也无法用于短信校验、去重等下游逻辑。

• 哈希值长度固定（如 SHA2_512 总是 64 字节），无法保留字段语义和格式
• 相同输入永远输出相同哈希，攻击者可用彩虹表反查常见手机号
• 没有盐值时，批量哈希可被并行暴力破解；加盐又导致同一号码每次哈希不同，失去可比性
• HASHBYTES 返回 varbinary，直接 SELECT 会显示为 0x...，需额外 CONVERT(VARCHAR, ..., 2) 转换，徒增开销

真正该怎么做：用表达式实现列级动态掩码

脱敏必须在查询输出阶段做，不改源数据，只改 SELECT 结果。SQL Server 中推荐直接写掩码逻辑，例如：

SELECT id, LEFT(mobile, 3) + '****' + RIGHT(mobile, 4) AS mobile FROM users

• 对 NULL 值要兜底：ISNULL(LEFT(mobile, 3), '') + '****' + ISNULL(RIGHT(mobile, 4), '')
• 身份证掩码中间 8 位：LEFT(id_card, 6) + '********' + RIGHT(id_card, 4)
• 若字段名来自参数（如 @col_name），必须用动态 SQL + sp_executesql，且提前校验字段是否在白名单中，防注入
• 复杂规则建议封装成标量函数，如 f_mask_mobile(@mobile)，再在 SELECT 中调用，便于复用和测试

如果真要用 HASHBYTES，只适合密码类场景

仅当目标是“防明文落库”且无需还原时才适用，比如密码存储。此时必须配合盐值和强算法：

• 盐值用 CRYPT_GEN_RANDOM(16) 每用户独立生成，不能复用
• 算法选 'SHA2_256' 或 'SHA2_512'，禁用 'MD5' 和 'SHA1'
• 哈希值和盐值必须分两列存储，不能拼接后存一列
• 验证时从库中取出盐值，再用相同算法重算哈希比对，而不是尝试“解密”

哈希的本质是单向校验，不是加密传输也不是脱敏展示——混淆这点，容易在合规审计时被直接否决。