如何设计安全的用户登录功能

(一) 老生常谈——口令
1. 口令长度与复杂度限制
限制用户输入一些非常容易被破解的口令，比如qwert、asdfg、123456、password之类的，参考twitter和 facebook的设计，为这样的口令做一个黑名单，不允许使用黑名单中的口令。同时，还对用户口令的长度、复杂度进行检查，要求用户设置足够长度，且复 杂度符合安全策略的口令。
在口令安全的这个方面，用户体验和安全可能是相对的。限制用户输入某些口令及口令的长度和复杂度，在用户体验方面可能并不太好。所以，很多成功且 设计良好的社交网站（SNS）都提供了UX让用户知道他的口令强度是什么样的，这样可以让用户有一个选择，目的就是告诉用户——要想安全，先把口令设得好 一点。
2. 不要明文保存用户的口令
用户都会用相同的ID相同的口令来登录很多网站。所以，如果Web应用系统明文保存口令的话，那么，数据被不良员工流传出去那对用户将是灾难性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，但不要直接使用诸如MD5或是SHA1之类加密算法。
3. 不要让浏览器保存口令
浏览器记住口令，对用户来说是很方便的事，因为用户不可能记住那么多的口令，只能借助于某些工具帮助记忆，浏览器只是其中的一种。但对于用户数据的安全来说，有很多方法可以获取浏览器记住的口令。所以，不要让浏览器保存用户名和口令。

(二) 用户登录状态
HTTP是无状态的协议，是无法记录用户访问状态的。用户的每次请求都是独立的无关联的，一笔是一笔。而我们的Web应用系统都是设计成多个页面 的，在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数 据。
我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令。为了实现这一功能，Web应用系统会把用户登录 的信息存放在客户端的Cookie里，每个页面都从这个Cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，Cookie的 使用并不是简单的事，下面是使用Cookie的一些原则。
1. 千万不要在Cookie中存放用户的密码
千万不要在Cookie中存放用户的密码，加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，一定不能把用户的密码保存在Cookie中。
2. 正确的设计“记住密码”
这个功能简直就是一个安全隐患，通常的设计是用户户勾选了这个功能，系统会生成一个Cookie。Cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。更安全一点的做法是：
1) 在Cookie中，保存三个东西——用户名，登录序列，登录Token
 用户名：明文存放。
 登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。
 登录Token：一个被MD5散列过的随机数，仅一个登录Session内有效，新的登录Session会更新它。
2) 上述三个要素会存在服务器上，服务器需要验证客户端Cookie里的这三个要素。
登录Token是单实例登录，意思就是一个用户只能有一个登录实例。登录序列是用来做盗用行为检测的。
如果用户的Cookie被盗后，盗用者使用这个Cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录Token”。而真正的用户 回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录Token” 不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况。于是，系统可以清除并更改登录序列 和 登录Token，这样就可以令所有的Cookie失效，并要求用户输入口令。并给警告用户系统安全。
3. 不要让Cookie有权限访问所有的操作
参考新浪微博的XSS攻击，即使Cookie有权限访问登录之后的所有操作。下面的这些功能一定要用户输入口令：
 修改口令。
 修改电子邮件。
 用户的隐私信息。
 涉及金钱的用户消费功能。

(三) 找回口令功能
找回口令的功能一定要提供，目前常用的找回口令功能大致有以下几种：
1) 安全问答。
事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更真实了，在facebook，开心，人人网，LinkedIn查到很多的真实的信息。
2) 重置用户的密码。
这有可能让用户的密码遭到恶意攻击
3) 安全一点的做法——通过邮件自行重置。
当用户申请找回口令功能的时候，系统生成一个MD5唯一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，然后设置 上时限（比如1小时内），给用户发一个邮件，这个连接中包含那个MD5的字串的链接，用户通过点击那个链接来自己重新设置新的口令。
4) 更安全一点的做法——多重认证。
比如：通过手机+邮件的方式让用户输入验证码，还可以使用数字证书、动态口令等方式。是否使用多重认证，主要取决于Web应用系统的重要性程度。
(四) 防御暴力破解
1) 使用验证码。
验证码是后台随机产生的一个短暂的验证码，这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。
事实证明，这是最简单也最有效的方式。当然，总是让用户输入那些肉眼都看不清的验证码的用户体验不好，所以，可以折中一下。比如Google，当发现一个IP地址发出大量的搜索后，其会要求你输入验证码。
2) 用户口令失败次数
设置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。
但是，这个功能可能会被恶意人使用，造成用户账户不能使用（这是一种变相的拒绝服务攻击）。更好的方法是，结合IP地址做验证，同时增加尝试破解 的时间成本。如，两次口令尝试的间隔是5秒钟。三次以上错误，帐号被临时锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时等等。如果发 现来自同一IP地址的错误次数太多，正确的做法是禁止这个用户在这个IP地址登录，而不是单纯的禁止用户登录。

 

登录是系统中最重要的一个功能之一，登录成功就能拥有系统的相关使用权限，所以设计一个安全的登录流程是十分必要的，那在一般登录中需要考虑哪些重要因素呢？请看本文讲述。

使用https协议进行传输，虽然麻烦，但是很强的保护措施，还没使用https的站点赶紧转成https吧。

强制用户使用有一定强度且复杂的密码，必须要有大小写加数字，长度在8位以上，杜绝像123456之类的弱密码。

密码不要明文保存到数据库，CSDN当年使用明文存储密码导致用户密码被完全暴露，这个事件影响十分严重。所以造成不要使用明文存储密码，要使用像MD5之类的散列算法加密存储，加密之前密码同时还要加上一个不固定的salt值一起拼接加密，一般md5(md5(password) + salt)就可以了，这个salt是盐，一起加密增加密码的长度也增加了破解的难度，盐一般设计为64位随机生成的字符串，最好分开存放，假如用户信息库被攻击了黑客也拿不到盐的库。不能使用可逆的算法，如果可逆，那如何保存密钥是个非常棘手的问题，一般使用明文加密与数据库中的密文对比就能确定密码正确与否，我们不需要知道用户的明文是什么，如果用户忘了可以通过重置或者密码保护问题修改密码，这也比总明文存储要好一万倍。

MD5现在已经不是十分安全了，最好使sha256，sha512之类安全强度更高的散列加密算法。

用户名密码错误不要单方面提示，如果密码错误提示用户说密码错误这样攻击者就知道用户名是对的，下次攻击密码，所以不管是用户名还是密码错误都给出同样的提示：用户名或密码错误，或者别的不具体的提示的错误都可以。 

前端禁止用户输入导致sql注入的字符，后台也要做sql注入的防护.

保存历史密码，一段时间没登录的用户再次登录时提示要修改密码才能登录，这时新密码不能和历史密码一样，苹果就是这么做的。

保存每次的登录信息日志，如果登录的IP与以往有很大差别（必要时可使用异地登录告警），要引导用户重置密码方可登录。

不要在cookie中保留用户密码，如果一定要使用cookie实现自动登录，切记不要使用简单的用户名＋密码MD5保存到cookie，要把用户ID、用户名、过期时间、IP、不固定的salt等一起考虑进去，这个当然要可逆，服务端要进行解密才能验证用户自动登录有效。另外，cookie要设置为http only,这样就不能通过脚本访问cookie，保证cookie的安全性。

不要让浏览器记住密码，虽然记住密码很方便，但也不安全，所以前端最好做控制。

一段时间类的尝试登录失败次数达到某个值，要锁定用户登录，如失败5次锁定24小时。或者间隔性锁定，如失败3次后锁定半小时，再失败1次锁定1小时，再失败1次锁定24小时。

设置会话有效期，比如登录后10分钟不操作就失效，要重新登录。

验证码使用，加上干扰线，防止计算机能够轻易识别，这样也可以防止黑客以程序的方式来尝试登录。

手机登录的一般使用短信验证码的，控制验证码的时效性，即验证码一次有效，一分钟内只能发送一次。

有必要的要采用单点登陆，如果允许用户多处登录的要给用户安全提醒。

重置密码最好通过邮箱发送一定时间内生效的重置链接，或者手机短信验证码，或者两者相结合的方法，像一般的大公司都有设计一个动态密码的东西，手机即一切，所以也要妥善保管自己的动态加密的APP，最好加上指纹或手势。

设置用户可以登录的IP，即IP白名单。像比如财务系统，限制财务人员只能在办公室登录系统。

可以考虑使用第三方授权登录接口，如qq登录，微信登录，微博登录，github登录等等，优化用户登录体验。

先总结到这，没有真正安全的登录机制，正所谓道高一尺魔高一丈，我们要做到与时俱进。
————————————————
版权声明：本文为CSDN博主「shadow_zed」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/shadow_zed/article/details/82425793