手机号一般用什么加密进行存储？

[rqxiao]

需求

数据库里的订单表的用户手机号不能以明文存储，现在是明文 希望以后数据库的密码都要密文存储

真要在业务代码里改，量有点大，bug 也会出现， 不知道有什么好办法

[zengxs]

数据库里面加密，不就是骗一下自己吗，建议 base64 就行

[TypeError]

aes，然后单独服务加解密，
查询时加一列 hash 来加索引查

[xuanbg]

2 楼方案可行。

[zoharSoul]

@zengxs 骗自己也要骗啊

合规要求

[Jrue0011]

之前刚好看到 ShardingSphere 有这种场景的解决方案

参考这个 https://shardingsphere.apache.org/document/legacy/4.x/document/cn/features/orchestration/encrypt/#%E5%B7%B2%E4%B8%8A%E7%BA%BF%E4%B8%9A%E5%8A%A1%E6%94%B9%E9%80%A0

缺点是又要引入新的中间件

[CommandZi]

@zoharSoul 这不掉进形式主义了吗

[zoharSoul]

@CommandZi
啥主义不重要,重要是国家要求就要办啊....

[leoleoleo]

数据库加密，是为了应对数据库泄露的情况下，攻击者如果无法获取到解密的算法和密钥，就无法利用泄露的数据。那么多金融机构用加密机，就是为了做这些事。。。。。安全本身就是递进的，跟前几楼说的骗自己有啥关系，用 base64 编码才是真的骗自己。。。。

[stevenkang]

订单表存用户 ID 就行了吧，干嘛存手机号呢。

用户敏感信息单独一个表，甚至单独一个系统来维护。日常需求从独立的系统中取出来就是脱敏了的手机号，合规又方便。

[jaylee4869]

我现在就在用 Apache Sharding Sphere 做脱敏。还是比较靠谱的，缺点是有 SQL 不能连表查询了。大多数 ORM 和连接池都支持。

[huihuilang]

我有个想法，把其中固定的一位去掉，比如把手机号第三位去掉，变成 10 位数手机号。。。然后去掉的那一位另外保存😂😂

[luozic]

gpdr or 国标？ 不是有推荐得实践么？

[jwenjian]

敏感数据不落盘 落盘要脱敏，这很正常的安全要求。不只是包括数据库，甚至日志文件都不应该有敏感数据原文出现。

密码明文存储 怎么着也说不过去，至少得存 hash 值 另外再加个盐。

业务代码肯定是要改的，安全这事儿 不出问题觉得是累赘 出了问题就麻烦了。

[mostkia]

手机号必须与用户数据关联起来才有价值，因为是 13 位的纯数字，乱按也是可以的。如果没有任何用户信息绑定到手机号上一起被盗，其实和打开拨号盘乱按的效果差不多。所以，加密用户敏感信息即可，手机号反倒不是重点，B64 处理一下就可以了，重点是让手机号和用户信息无法对应起来就可以了。

[mostkia]

11 位数字，更正

[rqxiao]

@stevenkang 额 这个系统有关用户信息只有手机号存储了，用户基本信息不做存储