这是一个创建于 2687 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在几乎所有的应用或网站都使用手机号码进行注册，这些服务的后台是如何存储手机号码的，是明文的还是加密的，或者其它方式？
第 1 条附言 2018-06-13 11:41:05 +08:00
呃呃，大家都觉得我的想法不实际。。
那，难道微信、微博、淘宝这些大厂里存的用户信息都是明文？
那，难道微信、微博、淘宝这些大厂里存的用户信息都是明文？
 | 1 xmh51 2018-06-13 09:37:24 +08:00 明文啊 这个一般不会是密文的。 |
 | 2 opengps 2018-06-13 09:40:28 +08:00 明文，不然怎么搜索 |
| 3 opengps 2018-06-13 09:42:55 +08:00 我曾经设计过一个系统： 存储当然还是明文，但是展示时候是 138****8888,然后支持精确查询来区分是不是同一个用户 目的： 用这种设计来避免号码被员工恶意拿走（页面上复制，拍照之类的），同时还实现了客服人员确认来电用户身份 |
 | 4 reid2017 OP |
| 5 opengps 2018-06-13 10:02:07 +08:00 |
| 6 reid2017 OP @opengps 互联网服务绕不开的问题是用户隐私，我使用你的服务，可以给你必要的隐私信息，这些信息仅限于给这个服务提供者使用，你得帮我保管好，不能泄漏出去（滑稽脸），所以如果存明文，一旦数据库被攻破，所有隐私信息都是肉眼可见 领导说要加密存储，那你也只能在代码里做吧，现在好像还没有可以直接在数据库里实现字段加密的吧 |
 | 7 janxin 2018-06-13 10:13:12 +08:00 你加密了怎么发短信？发短信之前先解密一下吗？ |
 | 10 chenqh 2018-06-13 10:41:35 +08:00  1 这话说的，互联网数据不就是用来丢的吗，那个公司没丢过 |
| 11 opengps 2018-06-13 10:47:27 +08:00 @reid2017 你应该考虑如何保护你数据库，而不单单是考虑软件加密角度。 保密等级高的数据库，估计仅仅内网开发，仅仅某些资深员工有权限接触 何况基于手机号，还是有很多联系的，要不你考虑下脱敏，比如最后 2 位数按照特定规则变换，同时做到好搜和脱敏，手机号单独使用某些外键关联走，这样至少脱裤可也需要花点难度构造原始数据 |
 | 12 x86 2018-06-13 10:51:29 +08:00 那你们所有字段都加密一次好了，怕运维看到 |
 | 13 lcy630409 2018-06-13 10:56:17 +08:00 楼上有位同学说的对，数据库里的资料运维和有数据管理权限的人肯定是可以看到的，，只有不可逆向的加密 才能不被获取到，但是手机号不被逆向了，自己的业务怎么用？ 这个还是管理层的问题，需要下发文件和规划好权限问题 |
| 14 lcy630409 &nbp;2018-06-13 10:57:20 +08:00 而且手机号这个东西太有规律性，你不可逆向加密了，只要我知道了加密方式 照样可以字典出来 |
| 15 opengps 2018-06-13 10:58:19 +08:00 安全是个综合体，别只考虑软件角度，正如楼上所属，能做到脱裤，怎么就不能拿走你源代码或者拿走你网站反编译源代码，最终还是不安全 你应该考虑各个层面做到自己该做的： 运维：人员可靠，系统基础漏洞封堵 开发：写代码注意别漏洞，别前台直接拼 sql 字符，一个 sql 注入拿到数据库 业务人员：别拍照或者复制页面就能拿走数据库的重要信息，别自己弱密码 管理层：别停留在表面上，做点实际的比如花钱上安全组件 |
 | 16 yulitian888 2018-06-13 11:02:19 +08:00 SQL Server 2016 新特性了解一下？ 关键词：Always Encrypted |
| 17 yulitian888 2018-06-13 11:04:52 +08:00 @reid2017 “现在好像还没有可以直接在数据库里实现字段加密的吧”，答：“有的！运维看到密文，程序读写明文” |
| 18 reid2017 OP @yulitian888 这么高级！可是不用 SQL Server... |
 | 19 3dwelcome 2018-06-13 11:11:28 +08:00 我们用的是一个自研数据库，每存一条记录，都是加密的。这样就算机房硬盘被人偷走，也不怕。 如果是常用的 mysql，最好把全文索引作为一个单独模块提取出来。这样存密文，就更不怕脱裤了。 |
| 20 reid2017 OP @lcy630409 其实没什么办法可以完全阻挡一个认真的黑客！或许加密，只是为了增加对方破解成本而已，不会像明文那样肉眼所见即所得。 |
 | 22 jjianwen68 2018-06-13 11:45:52 +08:00 via Android 手机号码没有那个系统会做加密吧，前台展示做某几位屏蔽不算 |
 | 23 yiqiao 2018-06-13 11:51:12 +08:00 见过一家只要涉及到用户隐私统统都加密后写入数据库中。要取出的时候解密出来 |
 | 24 tadtung 2018-06-13 11:54:08 +08:00 via Android 自然是明文了。你做的话也会明文存储的。 不过似乎早上有新闻说是 a 站和摩拜被黑，用户数据被泄露，似乎刚刚就有在 tg 卖数据的。 |
 | 25 gamexg 2018-06-13 11:54:48 +08:00 手机号基本是两个用途， 1.对比是不是一个手机号 2.发送短信通知 对于第一点，hash(盐+手机号)可以实现加密，不过为了查询方便，盐需要全站一致。 对于第二点，只能用加密方式解决了。 也可以这么做，发送短信部分独立为一个微服务，用户注册时提交用户手机号到微服务，微服务返回一个编号，数据库只保存这个编号，下次发短信提交编号到微服务的方式来发短信。 微服务内部再实现上密钥加密保存手机号。 但是我想不会这么实现的，太麻烦了。 |
 | 26 wu181184 2018-06-13 13:16:11 +08:00 可以有专门的加密存储系统，能够根据配置，针对各个服务的各个字段进行加解密，秘钥可以周期性自动更换（ KMS 了解下），至于效率，如果用 AES128，有硬件支持（ AES-NI 了解下），效率根本不是问题 |
 | 27 whypool 2018-06-13 13:49:28 +08:00 就明文存，简单省事 至于泄漏，那就泄漏了 |
 | 29 JCZ2MkKb5S8ZX9pq 2018-06-13 21:03:08 +08:00 我觉得因为能被解密，有漏洞，所以干脆不加密，这个逻辑不成立啊。 虽然再结实的门都有可能被炸开，但金库的门，用个木头的门加个小插销，显然是不合适的。 |
 | 30 strongcoder 2018-06-13 21:40:55 +08:00 via iPhone 手机号早都泄露几十万遍了 |
 | 31 mingyun 2018-06-13 23:31:08 +08:00 存储肯定明文，显示可以处理嘛 |
 | 32 shuhao 2019-03-12 21:48:43 +08:00 手机号，邮箱，银行卡这些涉及用户隐私的都要对称加密 |
Select Language