程序员过关斩将--少年派登录安全的奇幻遐想

“
据说，这篇也是快餐，完全符合年轻人口味

说到登录，无人不知无人不晓。每一个有用户体系的相关系统都会有登录的入口，登录是为了确认操作人的正确性。说到登录安全，其实是一个很伟大的命题，不过常用的手段也不过尔尔。

避免明文

这个设计到用户凭证信息的表设计，切记避免明文存储用户的密码信息。还记得以前很多大厂的密码泄露事件吗？

在数据表的设计中，除了用户密码的摘要列之外，需要添加所谓的“salt”列，其实是随机生成的一个字符串，用于和用户密码的摘要联合生成最终的摘要。

loginName	salt	pwd
182xxxxxxxx	随机字符串	散列值
182xxxxxxxx	随机字符串	散列值

如果非要写一个过程的话：

当用户首次注册的时候，系统随机生成salt，然后和密码按照规则拼接成一个字符串，然后求散列值，并存储在pwd列中
客户端请求登陆接口，上传用户的账号和密码，这里的密码推荐md5的摘要（js也可以生成md5）
服务端接收到请求，根据用户的账号查询对应的salt
把上传的密码和salt根据规则拼接，然后生成摘要
把上一步生成的摘要和数据库的pwd进行对比，相同则登录成功，不同则登录失败

为什么非要加入salt呢？有了salt不仅可以加大黑客破解的难度，而且同样密码的用户存储的pwd列也不相同，在用户信息安全性上又提高了一点。

验证码

验证码是一种比较廉价的但是很有效的防止别人乱搞的手段，它通过一种只有真人才能识别的防伪手段来阻止危险。

image

以上是12306的登录界面，看验证码的方式，是不是已经骚到了极点。如果你的登录接口不希望别人暴力破解的话，验证码是必须的。

对于普通的网站，验证码程序其实可以做的很简单就足够用了，就像以下

image

用到的技术是服务端把验证码的内容绘制在一张带有纹路的图片上，把码的内容存储在一个地方，并分配一个key，把这个key返回客户端，当客户端登录的时候携带者这个key和用户填入的验证码内容来确定验证码是否正确。

“
我曾经看过有人把验证码的校验放到客户端，要记住，客户端其实是无安全可言的，哪怕是那些做了混淆的App。

手机验证码

目前几乎所有的系统都支持手机验证码登录，为什么这么普及是有原因的。

首先，这种方式便捷，用户无需记住密码，试想一下，用户要记住自己常用的几十个网站密码是很难的，而且手机现在几乎都不离身
其次，手机验证码方式安全系数比较高，因为手机号现在都采用了实名制，手机号被盗的可能性比较小，而且现在的手机都有指纹锁，就算手机丢了也不怕
最后，系统都采用手机号登录，可以高效的拉进和用户的距离，而且也有利于国家的监管工作，毕竟根据手机号就可以追踪到用户的所有信息了

设备号

登录的时候把当前设备的标识上传到服务端进行识别，我觉得对于登录来说很重要。为什么呢？

在现在App漫天飞的时代，在App上是要实现自动登录的，换句话说，用户登录过一次这个App，当用户下次打开的时候，需要实现自动登录，这在用户体验上会比每次都登录好很多。但是这就面临着一个问题：需要把用户登录的凭证保存在本地，切换到浏览器中，这些凭证信息可能会保存在Cookie中或者local storage中，当然凭证肯定是要加密的。我们要保证的是这些凭证就算是被黑客知道了，也不能正常登录。

那怎么才能保证呢？答案是设备。在用户的登录请求中一定要上传设备号（浏览器也可以用js生成的），服务端存储着用户的有效设备列表，当然这个有效设备需要产品经理给出明确的定义，比如最常见的：登录过5次的设备。当然说到设备还有一个主设备的概念，至于怎么样才能定义主设备，也是需要产品方给出定义的，像最常见的：手机端是主设备。像微信现在登录pc端是需要手机端扫码的，切换到业务，可以看做需要主设备确认的请求才能执行。

安全设备概念在多点登录的场景下非常有用，尤其是需要互踢的需求下。