为什么要在存储密码时加盐

本人并非专门研究密码学的，只是业余使用，内容可能有误，感谢理解指出。

最近看见一个学长正在给我们学校的一个系统新增功能。他问我某个功能的实现的时候，我也看了一下代码。整个后端是用 PHP 写的，将学生的数据全部存在了一个本地的 MySQL 的数据库中。对于这种祖传代码，我本来已经对代码的屎山程度有一定心理准备，但是看见密码就这样，明文存储在数据库中的时候还是小小的震惊了一下我。并且很不幸的，我在他本地部署的版本上，找到了注入漏洞。

他随后给我看了新的代码，他通过了 MD5 加密了密码。按理来说，这样处理对于这个系统来说应该已经够安全了。但是他的代码中并没有给密码加盐。于是我当着他的面，找出了他自己账号对应的密码，随便打开了一个在线 MD5 解密工具，轻松的查到了结果。

为什么非对称加密后，还能查到呢？一般来说，这样的在线 MD5 解密工具的原理是通过提前在后台尝试大量明文的组合后加密。

已知 “AAA” 经过 MD5 后，可以得出 “E1FAFFB3E614E6C2FBA74296962386B7” 这一串。工具网站通过尝试各种字母数字的组合，暴力破解，算出字符串对应的密文，存储在一个数据库中。当你去查询的时候，工具从后端查询数据库，是否有已经解密的记录，有的话就直接显示出来即可。

但是这是不加盐的结果。什么是加盐？其实“加盐”这样的操作，只需要你在要加密的明文后再拼接一段字符串。字符串可以是固定的，也可以是随机的。有的系统会在数据库中存储每一个用户的 Salt 值，在处理用户的密码时，拼接在密码的一个固定位置，可以是前面，也可以是后面。这样，加密的结果就会完全不一样。

用刚刚的例子来说，我们假设盐值是 “asddsa”, 拼接在明文 “AAA” 的后方，我们最终要加密的字符串就变成了 “AAAasddsa”, 再加密的结果就变成了 “D147442CF4D83566492A03A9D4647B14”. 可以看见，和上方直接加密的结果也完全不一样了。如果还想通过暴力破解的方式获取明文，就需要先知道你固定的盐值，并且从零开始破解。因为在这样的加密算法中，明文哪怕是有一丁点不一样，都会导致最后的结果不同。如果是统一加同一个字符串进去，攻击者可以针对你网站来进行暴力破解，但是相对于什么都不加来说，已经提高了攻击成本。如果每一个用户所加的盐值都不一样，那攻击成本将会更高。