谈谈登录密码传输这件小事

背景

大大小小的系统其实都离不开登录这个小小的功能，前段时间老黄在审查公司部分系统代码时，发现不少系统的登录还是很粗暴的，粗暴到让人不敢说话的那种。

说到登录，结合标题，其实大部分人应该都猜到那个粗暴到让人不敢说话的是什么问题了~~~

密码明文传输，确实是很简单粗暴的一种做法，但是带来的风险也是可想而知的。

后面老黄就抽时间去看了一下我们比较熟悉的大网站是不是也会有这种情况。

#1 下面是一个财富网站的登录接口，可以看到他们的也是挺随意的，密码也是明文传输的。

#2 下面是一个旅游相关网站的登录接口，同样也是明文传输密码的，一不小心，还用13800138000成功登录上了他家系统，吓得老黄瑟瑟发抖~~

其实这样的案例是数不胜数的，知道个大概就好了~~

上面两个就是实打实的反面教材，再来看看几个好一点的案例，有个鲜明的对比。

#1 唯品会的登录接口

可以看到vip还是稍微严谨一点的，至少让别人猜不出来这个密码的原文是什么。

偷偷看一下js代码，可以发现是MD5了一下。

#2 拉勾网的登录接口

看上去传输的内容也是MD5过后的内容。

去看一下js代码，可以发现，拉勾传输的密码还略微复杂了一点，不是单纯的MD5，是两层MD5和加盐的结果。

上面两种是比较常见的做法了。下面再来看一个稍微不一样的。

#3 知乎的登录接口

可以看出，他们比较狠，参数是什么都不给我们看了，一点人性光辉都没，传输的内容都是完整的密文。具体是什么加密方式，这里就没有继续去看了，不外乎对称和非对称加密两种比较常见。

从上面3个密文传输的案例就可以大致知道，密码传输，我们的可选方案是什么。

90%的系统，用前面2种就可以挡住不少坏人了，毕竟想撞库，也是要花不少时间的。

其中对于使用hash的方案，除了用MD5以外，还可以考虑用SHA1或SHA256等。

如果真的要用加密的方案，可以用RSA+AES的组合方案。

在传输层做了不可逆的参数传递，那么后台接口要怎么处理呢？

后台接口，在登录的时候，主要是进行验证，验证的话，就取决于创建用户时，写入数据库的密码，是对这个传输的密码做了什么操作。

所以在验证的时候，照葫芦画瓢即可。

最后老黄采取的方案是双重MD5+加盐。