如何应用哈希+盐加密手机号？
解读
面试官问“如何应用哈希+盐加密手机号”，并不是想听你背一段代码，而是考察三件事：
- 你是否知道手机号在国内属于“个人敏感信息”，一旦泄露公司面临**《个人信息保护法》第六十六条最高五千万元或年营业额5%罚款**；
- 你是否能把“加密”与“用户运营场景”结合起来，既保护数据，又保留拉新、促活、留存、召回所需的业务可用性；
- 你是否具备数据落地能力：用什么算法、盐怎么存、密钥怎么管、如何兼容存量历史数据、如何给BI/算法团队开“最小可用”权限。
一句话：让技术合规，让运营还能用。
知识点
- 哈希算法选择：国内合规默认SM3（国密算法），如果公司暂未过密评，可过渡使用SHA-256+国密HMAC，但必须在PIA（个人信息保护影响评估）里说明理由。
- 盐（Salt）生成规则：16字节以上随机CSPRNG，禁止用时间戳或手机号本身做盐；盐必须全局唯一（每用户每字段），存储时与哈希值分开表或分库。
- 密钥管理：盐如果二次加密，需走KMS/HSMS（阿里云KMS、腾讯云KMS、物理机密机），禁止把密钥写死在配置中心；密钥轮换周期≤90天。
- 业务可用性方案：
- 精准营销场景：哈希后无法反解，可再生成可逆令牌Token（AES-256-GCM，密钥放KMS），Token只用于短期活动投放，有效期≤7天，活动结束立即销毁。
- 画像/look-alike场景：把11位手机号脱敏后6位+哈希前3位做分桶键，既模糊又保留统计意义，方便模型训练。
- 存量历史数据：先灰度双写（明文+哈希并存），验证召回率、短信到达率无差异后，再分批次删除明文，删除操作必须走数据生命周期工单，留存审计日志≥3年。
- 合规审计：加密改造完成后，需要输出**《个人信息去标识化报告》，并到省级以上网信办做认证备案**，否则无法通过APP年度安全评估。
答案
“在我上一份用户运营工作中，我们把手机号从明文改为哈希+盐的核心思路是**“不可逆、可运营、可审计”**。
第一步，算法与盐：选用国密SM3，盐长度16字节随机值，用Python的secrets.token_bytes(16)生成，确保每个用户每次注册都重新生成盐；盐与哈希值分开存在用户中心库和加密专用库，两库权限互斥，DBA只能看盐，看不到哈希。
第二步，密钥管理：盐本身再走一次AES-256-GCM加密，密钥托管在阿里云KMS，接口调用用RAM角色+STS临时令牌，有效期15分钟，防止内部员工拖库。
第三步，业务兼容：
- 短信召回：运营后台输入11位手机号，前端实时计算SM3(手机号+盐)，通过哈希值索引匹配用户ID，再调营销通道发券，全程不落地明文；
- 裂变拉新：老用户微信分享时，把好友手机号哈希后调活动API查是否已注册，未注册则发新人红包，接口返回脱敏手机号138****1234，既保护隐私又方便老用户识别；
- BI看板：给数据团队开通**“哈希分桶表”，只暴露前3位+后4位哈希前缀**，用于城市级别留存分析，无法还原个体。
第四步，存量清洗：用DataWorks建无锁任务，每天凌晨处理200万条，双写比对无误后，把明文字段置空并覆写磁盘，操作记录同步到日志审计中心，保存3年零6个月。
上线三个月后，我们的短信召回转化率从20.1%微降到19.7%（在置信区间内），合规审计零整改，APP安全评估一次通过，用户投诉量下降42%，真正做到了**“数据不可用，业务可运营”**。”
拓展思考
- 国际业务怎么办？ 如果用户来自欧盟，手机号哈希后仍属于GDPR“可关联”数据，需要再加 Pepper（系统级密钥）并走假名化（Pseudonymisation）流程，同时提供用户数据可携权出口，复杂度翻倍。
- 动态盐 vs 静态盐：动态盐每行一个，安全性高，但分库分表后跨库join性能下降；可引入布隆过滤器+Redis缓存做哈希前缀索引，把查询耗时从800ms降到40ms。
- AI模型冷启动：哈希后无法做手机号向量相似度，可用隐私计算里的联邦特征哈希（Federated Hashing），让运营商与平台在隐语/ FATE框架下共建加密向量，既合规又能复用运营商标签做look-alike扩量。
- 面试加分项：主动提到**《GB/T 35273-2020》国家标准第5.2条“去标识化”要求，并给出PIA模板**（数据映射-风险识别-措施落地-残余风险评估），让面试官直接感知你**“懂法规、懂技术、懂业务”**的三重能力。