网井过来做安全评估，说要对手机号做加密(唯一登录字段)

base64 或者 AES 或者 DES，或者 MD5，反正你加密不加密查询都一样的效果，加密只是多了一层性能损耗。

你这个是脱敏，直接搜脱敏关键字就可以了

什么行业的项目，网警会来过问数据字段的安全？

明文保存？

@okwork 电商，我也不清楚为什么突然就过来问了。第一次遇见这种情况。

aes 呗，都用同一个 key

@ccoming 手机号这个字段是用来注册登录的，没有其他标示字段，所以是明文的

明文保存的确不好。

@uoddsa 在他们来之前有没有国内商业安全公司向你们推销过安全产品或安全服务

aes 加密即可，查询的时候先加密再比对

网警这也算做了件好事。

这个要求比较奇怪，大厂也不会加密吧，否则发送短信通知怎么发？

跟你是用来做注册登录的唯一字段不冲突啊，你只要能保证加密不冲突，可以正反向加密解密，无非就是在 DB 里存的是 13800138000 还是一串乱码一样的字符串

@okwork 又没有说只能单向 hash 加密，密钥在自己手里，也可以做可解密的加密啊

楼上有人提到了关键点：脱敏。就是如果你被人拖库了，如果没有解密密钥，人家拿到就是一串乱码，但如果直接明文存，那就有好多黑产可以玩

@whusnoopy 可以解密的“加密”只能算混淆吧，密码 hash 可不止防脱裤，连内部员工也能防（手动修改字符串的方式不算）。

@okwork 但是手机号给 hash 了的话，还怎么给用户发短信啥的呀

@zacharyjia #16 要发送之前解密，比如，单独一个加减密服务来做加密解密操作，其他服务不需要的时候，都是加密的手机号来进行操作，楼上也说了原因了

显示的时候，135****1234 这样就好了，
至于数据库储存，网#不会看你数据库逻辑吧。
如果真看了，那就 base64 就 OK 了。

做个 HASH 就行了。用户登陆的时候，先做 HASH，再到数据库里查这个 HASH 就行了。

@zacharyjia
@scofieldpeng

我觉得这个是掩耳盗铃。既然别人都能脱裤了，程序中解密的算法一样可以被“脱”呀，这种可逆的加密有毛用？

@okwork 你都不看新闻，新闻经常见脱库， 有多少个服务器代码被扒了。这种方式好处就是只有两者都丢失，才会丢失正确数据。

对称加密，找我们公司

@LZSZ 请教，你不明文保存手机号码，要如何发短信？难道用可逆加密方案？那有意义吗，秘钥一样不安全啊

@luanluan 秘钥你们怎么确保安全？万一泄露怎么处理

@okwork 算法无所谓的。比如用 AES 加密，密钥并不在数据库中，那么被拖库也并不能还原出手机号码。

进一步说，解密的密钥甚至可以保存在硬件模块中，有单独的服务器集群提供解密的 API，仅供内部其它有权限的服务器调用

@okwork 现代密码学加解密算法都是公开的，不依赖算法保密性。保证密钥不泄露就好了，解密的密钥不要硬编码，可以从其他地方读取加载。

@abcbuzhiming 硬件密钥

其实就是让你们不要明文把手机号和一些其他信息直接存到数据库里面，怕有人拖库就直接能看到敏感信息。你们需要做的就是在程序入库前加一次密，用之前解密就好了，程序里面跑的都是明文没关系，但是落盘的时候不能明文。

@DavidNineRoc
@dorentus
@yedanten
@binux

上硬件密钥方案，那已经是物理级别了，不在网络和软件层面的安防讨论范围啦。

加密就加啊，唯一字段又不需要明文，用户登录提交的手机先加密，再和数据库的做比对，就行了

@okwork 现在云服务都提供硬件加密的

1.建议加密
2.不要用 base64/md5
3.拿"密钥可能泄露等于没什么用"来杠的纯属杠精

楼上竟然有几个人觉得对称加密就不是加密了

数据库未必需要加密，但是列表展示时候最好不要明文展示，防止信息泄露

数据库的安全应该是首要考虑的问题吧，做个什么产品默认都要考虑被脱裤吗？

@okwork 对称加密怎么就不是加密了啊，不然怎么有加密解密这样的反义词

关键的问题是脱敏，比如你的手机，解锁后啥都能用，但不上锁的话随便路人捡到马上都能用，不能因为你能解锁就说这一层锁没意义吧

@okwork 谁告诉你脱裤的时候代码也脱了。

代码获取还得拿到服务器 shell 权限。为了防止 github 泄露问题，密钥还可以单独保存

如果你们公司不是国企的话，加不加密跟 WJ 有个毛的关系?

@iyaozhen 不是说程序不能脱，是脱程序还是为了脱数据，数据安全的前提就是程序要安全，连业务程序都能被人入侵修改，那数据都是脏的。

没有绝对的万无一失的安全。所有的安全都是 概率 vs 成本。
但就跟多因子校验一样，多一项异质、异构的因子，安全性能将大大提升。
假如数据库被脱裤的风险是万分之一，代码泄露的风险是万分之一，那两项同时失密的风险是多少？

@yzkcy #32 +1.非得说密钥会泄露没用的真的是杠精。现实就是被脱库的很多，代码泄露的还是比较少。
@cdwyd #33 不理解+1.如果那样不算加密，那解密又是什么了？

看了这么多评论我简直惊呆，对加密解密的认识，对数据保护的认识完全不够。举个简单的例子，如果程序加密了，那么能接触到数据库接触不到程序的人至少就不可能直接看到用户隐私数据。又打个比方，比如苹果，谷歌，如果加密存储没有用，那么各位上传到云端的照片数据是不是也都会被苹果谷歌的员工看到？厂商宣称的隐私保护还有什么用呢？

明文传输？随便加密一下就好了。都是应付检查

加密的手段很多啊
你说密钥存在磁盘上不安全我存在 u 盘里插入进内存启动后拔了可以吧 你说密钥不能放 u 盘我还有专门的电子 key
想让数据跟密钥分离手段太多
要不咱在讨论下内存 dump 的问题？

看怎么要求的，数据库字段也要加密的话用个对称加密就行了。不要求直接加个脱敏字段，前 3 后 4。
手机又不是卡，应该没那么严格吧。

@hhhsuan 等保 2.0 和网络安全法，基本把所有非涉密系统和个人家庭 wifi 以外的网络服务全算进去了，总有一条可以做依据=_=

做安全的....现在接触的网警都是各种缺人手，黑产什么的事情忙不过来。。。你这是哪儿的网警，这么有闲情逸致=_=

1、过一个对称加密；
2、权限控制有且仅有加解密算法能够读取密钥；
3、程序逻辑上控制加解密算法的调用情况，每个调用加解密函数的地方需要写入文档并 Code Review 确认如果条件允许技术过关，采用注记（ Java ）、修饰符添加属性（ Python ）等方式标记被允许的调用方，并且加解密函数采用反射、自省的方式来检测调用方是否被如此标记；
4、对这些位置进行 Code Review，以确认确实有需求来进行加解密。

其实有 Dataflow diagram 也不需要 3，只需要看一眼图就行。

1 保证要脱库必须访问该密钥，将 “唯一性” 和 “隐私性” 分离；
2 保证不能直接接触，只能间接接触，并且接触方是无菌的，这就像是橡胶手套；
3 保证间接接触也是有权限的；
4 保证有权限的是有需求的。

手机号脱敏算很基本需求了吧，从去年开上强推等保，什么手机号，邮箱，身份证个人信息都需要加密处理

加密存储了 like 搜索怎么办？

来个实际的，用 bcrypt，别乱用 base64，md5 之类的东西

@abcbuzhiming 不会 我们的密钥进行加密的 而且生产密钥同时需要 2 个成份合成， 加密机设备，硬件，不会存在脱裤等

加密唯一的影响就是查询了，想不出来加密后怎么模糊查询

自己写一份对称加解密，然后告别模糊搜索就行了

是不是说数据库不能存明文

手机找回密码怎么办？

说一个我用的方法。
用 AES 加密，但是各部分用到的不同 AES 的密钥，所有密钥本身是 AES 加密保存的，程序启动后，需要输入主密码。即使代码被 shell 拿到了，没主密码也不知道真正密钥是什么。而解密后的密钥是在程序运行内存中，在不重启程序的情况下，想获取也比较困难。
要想获取到真正的文本，需要三样东西：数据库，密钥文件，主密码。

@yangbotool 问题是想查某个手机的数据不好查了吧，还要折腾一堆东西。

@dvaknheo 没有不好查，和上面说加密都是一样的。可以 HASH 出一个字段做索引。获取真正手机号时用 AES 解一下。只是多一步密钥加密，密钥不在代码里，多一道步骤，安全性可大大提高。

两个字段，一个加星号的号码，用来显示；一个 MD5，可加盐，用来登录

问个题外话，id 在什么情况下会用到模糊查询？
模糊查询应该不会对外开放，要不然就人来做账号测试了吧？

@yangbotool 等一下，你这个方式如何做模糊查询，我没想明白

@hhhsuan 『网络安全法』

@w0nglend 那淘宝里面的手机号，卖家都能直接看到买家手机号的，也是没有打星号的。

很多人已经提到了，核心是脱敏。
密钥可以和数据库分开，反正假如数据库被入侵，看到的都是乱码，且入侵者无法采用常规加解密算法获得数据即可。

弄个可逆的加密就行了

总结一下：
1 密钥放 HSM 不能拿出来
2 对称加密还是不对称加密不是重点
3 存放 md5 等 hash 值是为了在不解密的情况下快速查询，因为解密速度慢
4 like 和 range 的查询是伪需求。但是如果想要快速查询尾号为 xxxx 的号码的话，就新增加一个 tail-index 字段。
5

5 密钥存放有策略，如果同一个产品给不同的委托方使用的话，每个委托方保留一个密钥，不可重复。
6 可以加加 salt 以提高安全性。具体看你的需求。比如信用卡号码安全级别就比手机号高。加 salt 的时候选取相对不变的字段。比如 ID 是每个用户唯一的，而且不变的字段用来做 salt 很合适。

@abcbuzhiming 模糊查询和肯定不支持了。但应该用不到模糊查询一个手机号吧? 其它分类信息如果你要用，可以单独分出来，比如运营商、区号。

如果是有国外用户，应该是为了满足欧盟 GDPR 的要求吧

@okwork 都是加密的，发短信的时候再解密就好了，有密钥就行