“据说，这篇也是快餐，完全符合年轻人口味
说到登录，无人不知无人不晓。每一个有用户体系的相关系统都会有登录的入口，登录是为了确认操作人的正确性。说到登录安全，其实是一个很伟大的命题，不过常用的手段也不过尔尔。
避免明文
这个设计到用户凭证信息的表设计，切记避免明文存储用户的密码信息。还记得以前很多大厂的密码泄露事件吗?
在数据表的设计中，除了用户密码的摘要列之外，需要添加所谓的“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端是需要手机端扫码的，切换到业务，可以看做需要主设备确认的请求才能执行。
安全设备概念在多点登录的场景下非常有用，尤其是需要互踢的需求下。
登录时间
服务端一定要记住用户最后一次的登录时间，在很多情况下需要记住用户在某个设备上的最后登录时间。这样做不止是为了记录分析用户的登录行为，还可以分析长期未登录的用户，使他的登录凭据失效，强制他重新登录。
HTTPS
虽然一个证书每几个钱，但是https起到的作用在安全性上还是很大的。本质上它采用的也是加密算法，比http要耗费cpu，传输速度上要慢一些。但是它可以有效的防止中间人劫持，防止用户信息外漏，而且可以防止被钓鱼网站攻击，有效识别网站真实身份，像其他的有利于SEO，地址栏出现安全锁等就不说了。
写在最后
以上所说只是一些最常见的手段，除此之外，比如IP黑名单机制，限流机制等都可以加固登录的安全。
本文转载自微信公众号「架构师修行之路 」，可以通过以下二维码关注。转载本文请联系架构师修行之路 公众号。
