总结：
一、用户信息之密码
讲密码的存储方案前，先要记住三条前提：
- 用户喜欢到处使用一样的密码
- 用户喜欢使用简单好记的密码
- 世界上没有绝对的安全，但当攻击成本远高于收益时，整个系统达到相对安全
Phrase 1：哈希
哈希保存的思路很简单：用户注册时，把他的密码做一次MD5运算储存起来；用户登录时，把他输入的密码做一次MD5运算，再验证是否和数据库里储存的一致。
在MD5被证明不够安全以后，大家又开始选择其他的哈希算法如sha256等。但除了哈希算法本身的安全性外，这种做法的缺陷很快暴露，就是应付不了彩虹表的攻击方式。
彩虹表就是把简单的数字密码组合（和各种常见密码）的哈希先尽可能的计算出来，这些明文和哈希结果的对应关系就是一张彩虹表。由于前提2（大家喜欢使用简单好记的密码），所以试着计算出一个常用范围内的所有字母组合的哈希的彩虹表，可以破解绝大多数人的密码。当彩虹表足够大时，这种存储方式实际上与明文无异。
Phrase 2：加盐哈希
加盐哈希是目前业界最常见的做法。
加盐哈希的步骤如下：
- 用户注册时，给他随机生成一段字符串，这段字符串就是盐（Salt）
- 把用户注册输入的密码和盐拼接在一起，叫做加盐密码
- 对加盐密码进行哈希，并把结果和盐都储存起来
在登陆时，先取出盐，再同样进行拼接、计算哈希，就能判断密码的合法性。
加盐哈希的做法，既保证了储存数据的不可逆，又防止了上一章的彩虹表攻击方式。这种方式下，黑客拿到数据库后，如果再要用遍历所有常用的密码组合的方式做彩虹表，那他需要对所有常用密码+盐值进行哈希运算。而每个用户的盐值都不相同，之前彩虹表的「一次运算无数次使用」变成了「一次运算一次使用」。这样的成本是难以接受的，由于前提3（攻击成本远高于收益，系统达到相对安全），所以这是一个比较安全的做法。
二、用户信息之手机号
对于手机号这种信息，只能用相对安全的做法，即先对手机号进行对称加密，再将加密结果储存在数据库里；使用时再用密钥解开。这时密钥不应该被保存在数据库里。如果数据库被拖库，那么些数据的安全性与明文无异。通常会将密钥以环境变量的形式放在服务器上。这时除非网站在被拖库的情况下同时被拿到服务器权限，否则手机号的明文就不会被泄露出去。
最后，谨防日志泄露用户信息：在后端项目生产环境里，总是会打印并收集各种各样的日志。日志可以方便统计数据、在出错的时候回溯、调试bug。但是我们不应该总是打印和收集全部请求的正文内容，因为请求里可能包含密码等敏感信息。当日志被泄露时，用户数据同样会以明文形式直接泄露出去。