一、场景
只要是个独立的平台，那么必然涉及到用户密码的在数据库的储存问题
二、历史
1、第一批
直接明文储存密码，比如你设置的密码是“123456”，那么数据库直接储存的就是“123456”
这种风险极大，一旦出现泄漏，后果是毁灭型的
2、第二批
使用散列
散列，也叫 HASH，或者叫“哈希”，简单说就是通过数学函数一样，把一个物件整整容，换了个模样。
散列的特点就是：
（1）不可逆。言外之意就是假如数据库存储的是散列后的数据，那么你反向推导来破解
（2）一个输入只会对应一个输出。所以就能用来验证用户的密码对不对。
（3）一个输出可能对应多个输入。这一点会增加破解的难度
散列的缺点也有，因为从输入到输出，它是一一对应的，所以就能嘿嘿，跑字典啊，我事先把所有对应关系跑出来，然后像查字典一样，一个个去匹配。
3、第三批
散列 + 盐值
盐值这个词看着很难理解，不过举个例子就明白了，比如你的输入就是一道菜，因为刚才讲了，散列是一一对应的，所以会容易被破解，那么我往这道菜里加点配料，那就不一样了，这个配料就是盐值。
比如用户真实密码是“123456”，它是一道原始的菜，我随意往某个位置塞点字符串进去（加盐值），那么它就变味了，拿去散列，结果就不一样了，最开始用的字典也就不起效了。