需求
数据库里的订单表的用户手机号不能以明文存储，现在是明文 希望以后数据库的密码都要密文存储
真要在业务代码里改，量有点大，bug 也会出现， 不知道有什么好办法
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2363 days ago, the information mentioned may be changed or developed.
 |
zengxsMay 15, 2020
1
数据库里面加密，不就是骗一下自己吗，建议 base64 就行
|
 |
TypeErrorMay 15, 2020
2
aes，然后单独服务加解密，
查询时加一列 hash 来加索引查 |
 |
xuanbgMay 15, 2020
3
2 楼方案可行。
|
 |
Jrue0011May 15, 2020
5
之前刚好看到 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 缺点是又要引入新的中间件 |
 |
8
数据库加密，是为了应对数据库泄露的情况下，攻击者如果无法获取到解密的算法和密钥，就无法利用泄露的数据。那么多金融机构用加密机，就是为了做这些事。。。。。安全本身就是递进的，跟前几楼说的骗自己有啥关系，用 base64 编码才是真的骗自己。。。。
|
4 |
stevenkangMay 15, 2020
9
订单表存用户 ID 就行了吧，干嘛存手机号呢。
用户敏感信息单独一个表，甚至单独一个系统来维护。日常需求从独立的系统中取出来就是脱敏了的手机号，合规又方便。 |
 |
lavvrenceMay 15, 2020
10
我现在就在用 Apache Sharding Sphere 做脱敏。还是比较靠谱的，缺点是有 SQL 不能连表查询了。大多数 ORM 和连接池都支持。
|
 |
huihuilangMay 15, 2020 via Android
11
我有个想法，把其中固定的一位去掉，比如把手机号第三位去掉，变成 10 位数手机号。。。然后去掉的那一位另外保存😂😂
|
 |
luozicMay 15, 2020
12
gpdr or 国标？ 不是有推荐得实践么？
|
 |
jwenjianMay 16, 2020
13
敏感数据不落盘 落盘要脱敏，这很正常的安全要求。不只是包括数据库，甚至日志文件都不应该有敏感数据原文出现。
密码明文存储 怎么着也说不过去，至少得存 hash 值 另外再加个盐。 业务代码肯定是要改的，安全这事儿 不出问题觉得是累赘 出了问题就麻烦了。 |
 |
mostkiaMay 16, 2020
14
手机号必须与用户数据关联起来才有价值，因为是 13 位的纯数字，乱按也是可以的。如果没有任何用户信息绑定到手机号上一起被盗，其实和打开拨号盘乱按的效果差不多。所以，加密用户敏感信息即可，手机号反倒不是重点，B64 处理一下就可以了，重点是让手机号和用户信息无法对应起来就可以了。
|
|
mostkiaMay 16, 2020
15
11 位数字，更正
|
 |
16
@stevenkang 额 这个系统有关用户信息只有手机号存储了，用户基本信息不做存储
|
Select Language