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

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

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

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

明文保存？

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

aes 呗，都用同一个 key

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

明文保存的确不好。

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

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

网警这也算做了件好事。

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

@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 保证有权限的是有需求的。

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