发现自己以前对登录这一块想的太简单了，遂总结补充一番。
- 首先我们要知道为什么需要给登录注册加密，简而言之，就是保护用户的账号密码不会被恶意获取
- 所以我们所做的一切都是基于此的。
- 所谓的安全性都是相对的，所以我们的目的不是设计无法攻破的密码系统，而是要尽可能的加大密码破解的难度。
密码的不安全因素
- 密码输入时的安全性
- 密码传输过程中的安全性
- 密码保存处的安全性
最常见的破解登录方案就是抓包，但是抓包的前提是他知道你是什么时候登录，另外你的网络能被对方捕捉到，比如你用不安全的 wifi 或者不安全的链接等。
针对各种因素的对策
第一次登录的情况
对于1，就是不能搞错了网址，基本没有问题。
对于 2,3 两种情况是一样的，就是都需要前后端进行加盐加密（这里还没有说完）。
如果后端不加密，一旦数据库被攻破，那么对方可以获取所有用户的账号密码，那这就是不可原谅的重大事故了。
同理，假设使用 http 协议传输，一旦数据被抓包，如果数据没有被加密，可以获取这个用户的账号密码也是非常危险的。但是我们也知道 http 传输都是明文传输的，只要是明文传输，那么抓包被截获后，对方可以在不需要知道用户的账号密码的情况下直接使用截获的数据进行登录验证，照样可以登录。
所以直白的来说，只要是使用 http 进行登录，都是不靠谱的。
因此我们应该使用 https 进行登录。
HTTP本身所有的数据都是不加密的。准确的说，HTTPS不是一种协议，而是HTTP和SSL两种技术的组合。SSL是Secure Socket Layer，安全套接字层，有时也成为TLS（Transport Layer Security），是介于传输层和应用层的一个拓展的层，可以透明的将应用层数据加密然后通过传输层送出去。因此，使用了SSL传输的HTTP报文，从HTTP Headers到主体都是加密的。
那么如果使用 https 登录还需要前端进行加密吗？这个问题要这么看：
尽管我们使用 HTTPS 加密了传输，但 HTTPS 的证书是谁给你的？这个证书链向上的任何一级都可以解密你的传输数据！所以它也并不是绝对安全的。但是话也说回来了，那好比存钱，你要是怕银行被抢，那你钱到底放哪里好呢？所以答案还是，可以不加。
首次登录之后的情况
我们知道首次输入账号密码登录后，再进行相关的操作都是不需要账号密码的，都是使用 cookie 或者 token 等进行登录。
以 cookie 为例。如果 cookie 被抓包获取那对方还是可以登录，这又怎么办？
答案是：没办法。但是我们可以降低它的风险。就是存储 cookie 时同时存储用户的 id（uid） 和 加密摘要，但是加密摘是用户登录随机产生的，一旦用户退出登录，数据库中删除之前的加密摘要，该加密摘要就没有意义了。除非用户再次登录，又被抓包。。。
延长破解时间
前面的都是通过加密加大破解的难度，但还是可以通过暴力破解，不断尝试来得到真正的密码。那么我们可以使用一个相对慢一点的加密方式，比如加密方式慢了 1s 中，那么破解难度就会几何级数的增长。
扩展：
获取用户之后怎么保持登录状态。这里就有两种机制 session（cookie） 和 token（uid）。为什么前后端分离要用 token 和 uid？可不可以使用 session 和 cookie？
1. 跨域产生的ajax是无法携带cookie信息的，但这个是可以解决的，而且也不复杂，另行谷歌。
2. 移动端是没有 cookie 的。
另外为什么我之前保存了 session 却没有起作用？因为服务器配置禁用了 session 中使用 cookie。正常情况下，保存 session 后，服务器每次与客户端进行交互的时候，会给客户端传递一个名为 JSESSIONID 的cookie，再由客户端传回以用来判断身份，具体是对应的哪个session，但是cookie被 禁用，那么不会传值了，所以无法知道具体的session，自然 session 失效了。但是我也可以通过其他形式传值，但是这样显然是没有必要的。这样就进一步加大了破解的难度了。
注：
为什么要使用加盐加密？
为了增大彩虹表等破解的难度。具体加盐方式，以数据库为例，用户手册注册时，随机生成一个 salt，加密后再加上原密码一起再次加密一次。分别把加密后的 salt 值和 加salt后加密的密码保存到数据库即可。
uid 的作用？
同一时空中唯一，其实就是类似于id，但是我们不希望别人知道我们到底有多少用户，或者他在我们数据库中的位置，所以用复杂的uid来替代
参考博文——
10 Things You Should Know about Tokens