数据库存储的敏感信息是否需要加密存储？

[FreeEx]

我做的一个开源项目其中存储了服务器的 IP 账号密码等信息，有用户反馈说这些信息明文存储在数据库不安全，希望进行加密存储，但是在进行查看等操作的时候还是需要进行解密的，密钥也需要写在配置文件里，加密操作是不是多此一举呢？

[mjVtb96d2bap2u3Z]

密码至少 MD5 吧，不然被脱裤子，岂不是直接看到私密处了？不排除记录的是用户常用密码。

[knightdf]

不存明文密码

[FreeEx]

@ali727 MD5 不是加密，这里指的加密是可逆的加密算法，类似 AES 。能脱裤极有可能是读取到配置文件了，也能获取到密钥解密数据了。

[cnxobo]

密码肯定是要存密文的，永远不会知道数据是以什么形势泄露出来的。
拖库、数据库权限、报表系统、数据库备份。。。

[chuckzhou]

是的，不要在 DB 里面存明文密码，万一被脱裤了就悲剧了。你把加解密密码的密码写在一个配置文件里面，用户可以自己设置这个密码。比如 php 的网站一般写在 config.php 里面。

[chinvo]

因为脱裤和任意文件查看通常不是同一个漏洞.

[crazyxtcn]

我们以前用户收货地址手机号之类的信息都要加密存储

[FreeEx]

@cnxobo 很有道理，但是查询的时候也要进行回显，是在后台进行解密再返回前端？

[yeqizhang]

你这种确实不像是存用户 md5 那种只做研制功能的特殊需求。 加密存一下相当于提高一下直接看到明文密码一点点难度吧，只是拉到数据库没黑进服务器的话，还是有一点作用的。

[yeqizhang]

@yeqizhang 研制-->验证

[ch2]

单独获得你密钥或者数据库的难度，要小于同时把两个都搞到，别一开始就假设所有入侵都是别人用非常高明的漏洞拿走所有的东西，有可能他只拿得到其中的一部分

[ruanimal]

@FreeEx 你见过有哪个网站有查询密码的功能？？ 不都是重新设置吗

[FreeEx]

@yeqizhang 如果黑进服务器的话好像就没什么特别的办法了，不知道类似 xshell 是怎么做的

[FreeEx]

@ruanimal 存储的是服务器的账号密码，做的是一个类似堡垒机的东西

[FreeEx]

@ch2 很有道理，看来加密存储还是有必要做的。

[zpfhbyx]

固定密码+随机因子啊。比如 密码 abcabc 随机因子 user_id 千人千面

[FreeEx]

@zpfhbyx 还需要解密的

[zpfhbyx]

@FreeEx 是啊。openssl 直接加密解密就行了。 我是说的秘钥。。

[3dwelcome]

加密一下好。
你看 chrome 网站保存的密码可以随时查看，但也是加密后保存到磁盘的。而且版本升级中间变过算法，可见 google 对密码安全还是比较重视的。
否则数据库被脱裤，黑客一看账户密码全是明文，都要笑的合不拢嘴。

[FreeEx]

@zpfhbyx 密码+随机因子+user_id 其中随机因子如果没存储的话重启就丢了。

[konakona]

密码肯定要加密啊

电商强烈建议可逆的序列化存储用户姓名、手机、地址这些敏感数据的密文，就简单的 hash 都好，被脱裤子了人家只会觉得你这家公司业界良心很厚道。

[learningman]

@3dwelcome #19 可是隔壁 edge 导入的时候没看 chrome 意见啊。。。

[FreeEx]

@3dwelcome 觉得加密存储了，开源项目用的加密算法就是直接公开的，加密的密钥只能让用户自己设置了

[3dwelcome]

@FreeEx 随机因子是加盐的意思，不会丢。可防彩虹表爆破。

[FreeEx]

@3dwelcome 我了解的 AES 加密只有 IV 偏移量，加盐在 MD5 里面用的比较多，请问你说的是哪种加密算法？

[jay4497]

@FreeEx AES 除了偏移量也有 key 的吧

[3dwelcome]

@FreeEx AES 也算加盐，因为 IV 设计的目的，就是加入随机数。
看你描述，和 chrome 一样要完全还原明文密码的，那只能用 AES 了。

[zpfhbyx]

@FreeEx user_id 就是随机因子啊。

[timethinker]

分两部分看：
密码一般不可逆，我们也没有必要逆向出密码的明文，因此属于哈希类的，只需要通过相同的哈希算法得出一致的结果就行，不关心它的明文到底是什么。

但是手机号等这类信息是需要可逆的，也就是加密之后还得解密，落地存储到数据库的时候到底要不要对此类信息进行加密，我记得三级等保是需要的，但是加密的一个后果就是无法支持区间条件查询，比如一个需求是查询所有以 188 开头手机号的所有记录，加密以后就无法进行范围匹配查询了，当然了，也可以有其他的辅助性的索引支撑，但是复杂性也会随之提高。

我又要唠叨一下了，没有绝对的安全，只能尽量保证在泄露数据之后，使泄露出去的那一部分无法单独得出有意义的结果，比如只是数据库被脱库了，但是没有应用代码的逻辑，即使拿到那一部分数据也是没有意义的。当然了，如果你的应用代码和数据库全被扒了，那么再好的加密措施也会变得没有意义，就看对方是否愿意花时间在这上面研究了。

[FreeEx]

@zpfhbyx 这样相当于把密钥写进数据库了，因为程序本身是开源的，加密算法也就相当于公开了，因此数据和不加密没有区别。

[FreeEx]

@qwe520liao 感谢回复，因为程序是开源的，所以加密算法也是公开的，此种情况下只能把密钥写到配置文件里面了，尽量保证数据安全吧。

[zpfhbyx]

@FreeEx 开源也没事。。随机因子去让用的人去配就好了。。反正也不知道是哪个。

[FreeEx]

@jay4497 AES 的 key 就是密钥。
@3dwelcome 把 AES 的密钥写到配置文件吧，这样至少还需要一个任意文件读取的漏洞才能解密数据。

[magicdawn]

之前做过手机号， 姓名之类的需要对称加密
有个包比较实用，https://github.com/magicdawn/node-mysql-aes