以一个农民工的名义对大家说，软件的健康与否关系着全国人的安危。君不见，几多时，一个软件漏洞便让多数人惊慌。不经意间，我们与软件的关系休戚与共。不幸的是，软件的健康状况不容乐观，瑕疵很多。

之前发生了logback、fastjson等漏洞跟程序员有很大关系，不修复可能面临轻则走人，重则公司倒闭股票下跌，但是今天这个事情，关系到多数人。

简单来说，就是被拖库了，什么意思呢？底裤都脱了，所以什么都可以看到了，如果重要信息已经全部泄漏，修改密码也无济于事。当然如果只是泄漏了一张人员信息表，还是建议尽快修改为更复杂的密码。

如上对于学习通发表的声明，就相当于没有说什么。

当然了你也可以对如上图中的明文密码进行再次加密，盐值可以使用随机生成，至于如何混淆，你可以在代码中自行设计。最后加密出来的 Hash 值就很难在彩虹表中找到了。即使找到，也只是上层拼接盐字符串的内容，用户的原文密码毕竟还有一层加密，而且这个加密逻辑对外是看不到的。这对于经常使用简单密码登录的用户非常有效。

对于用户而言，一些重要的网站帐号、密码尽量还是使用不同的内容，如果记不住的话，可以使用一些带加密能力的记事本软件进行保存，这样会更加安全。

而作为软件的研发人员，要对自己的产品负责，应该始终都将用户的密码及重要信息进行加密处理。这是最基本的职业道德规范。如果都做如上声明，互联网将命不久矣。

说到点子上了，重要信息也要加密处理，人家都已经把库搞到手了，管你用什么密码，反正我已经拿到数据了，这就要求我们对敏感信息进行加密了。

简单做法可以在数据库实现加密算法函数 decode，在模糊查询的时候使用 decode(key) like '%jiaoyutong%

在数据库中实现与程序一致的加解密算法，修改模糊查询条件，使用数据库加解密函数先解密再模糊查找，这样做的优点是实现成本低，开发使用成本低，只需要将以往的模糊查找稍微修改一下就可以实现，但是缺点也很明显，这样做无法利用数据库的索引来优化查询。而且数据的加密跟业务实现可能不一致。

如果上面满足不了查询要求，那么对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'，这是一个比较经济的实现方案，先来说下它的实现思路。

先对字符进行固定长度的分组，将一个字段拆分为多个，举个例子：

jiaoyutong使用4个字符为一组的加密方式，第一组jiao ，第二组iaoy ，第三组aoyu ，第四组oyut … 依次类推。

如果需要检索所有包含检索条件4个字符的数据比如：jiao ，那么就把 jiao 加密字符后通过 key like '%partial%' 查库。

这个方法优点就是实现起来不算复杂，使用起来也较为简单，算是一个折中的做法，因为会有扩展字段存储成本会有升高，但是可利用数据库索引优化查询速度，推荐使用这个方法。常规情况下，敏感信息大多是手机号、身份证号，我们可以使用部分字段加密技术做到，比如可以只保留手机号的后四位明文，前面部分加密，搜索只能根据后四位，所以会更简单。

有兴趣的话可以参考下一些互联网平台上的常见方案：

这里有兴趣的可以参考，

总结

到这里差不多也就啰嗦完了，总的来说，不要说安全复杂了，其实很多加密方案都是几十年前的了，这块知识一直没有怎么变化，但是安全呢？它不仅仅是一门朴素的学问，更是一门权衡的艺术，要从投入、产出比、及综合技术实现考虑，从而经济实惠的保证数据安全。