场景：
某个App使用手机号注册并设置密码，成功后该用户即开户成功。我们登录密码传输到后台基本上都使用md5处理。但是仅仅简单的md5对于那些简单的密码（比如123456）还是容易破解，所以我们一般还会加盐处理。
第一种情况：前端，app端都使用一个固定的盐（定义一个很复杂的字符串，还可以将该字符串先md5后的值当作盐），这种处理确实已经非常安全了，但是会不会就完美了呢？NO，使用固定的盐那么不同的用户如果设置的密码相同（比如明文：123456），那么在数据库中存储的密文就会是一样的，那么公司内部管理数据库的人，假如他也使用的密码是123456，那么他就可以使用他的密文去数据库去查找有没有其他用户的密文跟他的相同，如果有就说明该用户跟他一样设置的都是123456。
第二种情况：上面第一种情况分析可知md5的盐首先要尽可能的复杂一点，二每个用户使用的盐最好是唯一的，不相同的。那么简单点很多app都是用的手机号码当作登录账号，手机号码绝对是唯一的可以很好的满足前面的需求，那就用手机号码（即登录账号）先md5得到的值当作盐。是不是又完美了呢？ NO, 使用这种方式可能会遇到下面的问题：
问题：app上一定有更换手机号的功能，一般更换手机号操作都是输入旧手机号，发短信，输入新号码，再输入登录密码(用旧手机号当盐值加密处理)，然后提交到后台校验这4要素。这里就有问题了，这4个参数检验成功了，账号就换了，以后就再也不可能登录成功了。
分析：假设原来的手机号132**** 设置的登录密码 123456，更换的新号码为187****
首先 ： md5( md5(132***) + "123456" ) = abcd****(真实的肯定不是这个值，暂当作这个值)
换手机号后： md5( md5(187***) + "123456" ) = qwer****（反正和之前的一定不相同的）
发现问题了吧，你还能登录才怪呢！！！
那如何解决这个问题？
我们在更换手机号那里再穿一个参数，因为现在页面本来就已经输入了新手机号，那么我们可以将用新手机号作盐的到的登录密码md5值也传进去，那么后台开始在比对以前的登录密码md5值一致后，就将数据库中存的登录密码替换成这个新的就ok了！
