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

用户登陆功能是Web应用系统具有的最基本的功能，关系到用户数据和应用系统数据的安全，设计一个安全的用户登陆功能，涉及到如下几个方面的内容。
(一) 老生常谈——口令
1. 口令长度与复杂度限制
限制用户输入一些很是容易被破解的口令，好比qwert、asdfg、12345六、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地址登陆，而不是单纯的禁止用户登陆。