SQL存储过程中使用HASHBYTES进行数据脱敏加密

先说一个常见误区：很多人把 HASHBYTES 当成万能脱敏工具，对着手机号、身份证号就是一通哈希，觉得这样就安全了。但实际上，这根本不是脱敏，而是彻底把数据“毁”了——不可逆、无语义，业务方拿到一串乱码，既看不出是谁的号码，也没法做校验。真正意义上的脱敏，是在保留部分可读性的前提下隐藏敏感信息，比如 138****1234 这种形式。所以，别再把哈希当成脱敏来用了。

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' 直接拉黑。
• 哈希值和盐值必须分两列存储，别图省事拼在一列里。
• 验证时从库里取出盐值，再用相同算法重算哈希来比对，而不是去“解密”。

哈希的本质是单向校验，不是加密传输，更不是脱敏展示。如果搞混了这几个概念，合规审计的时候大概率会被直接打回。