《
你会做用户登录功能吗？_》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/110AW2012.htm
--> Web上的用户登录功能应该是最基础的功能了，可是在我看过一些站点的用户登录功能后，我认为很有必要写一篇文章教大家怎么来做用户登录功能。下面的文章告诉大家这个功能可能并没有你所想像的那么简单，这是一个关联到用户安全的功能，盼望大家能从下面的文章中能知道什么样的方法才是一个好的用户登录功能。以下内容，转载时请坚持原文一致，并请注明作者和出处 。
用户名和口令
首先，咱们先来说说用户名和口令的事。这并不是本站第一次念叨这个事了。如何治理本人的口令让你晓得怎么管理自己的口令，破解你的口令让你知道在古代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告知从开发者的角度上来做设计这个用户名跟口令的事。下面一多少件规矩：
限用户输入一些十分轻易被破解的口令 。如什么qwert，123456, password之类，就像twitter制约用户的口令一样做一个口令的黑名单。另外，你可以限度用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户觉得很不爽，所以，当初很多网站都供给了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个抉择，目标就是告诉用户——要想安全，先把口令设得好一点。
千万不要明文保存用户的口令 。正如如何管理自己的口令所说的一样，许多时候，用户都会用雷同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，假如你的数据被你的不良员工传播出去那对用户是灾害性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对海内公司的操行以及有关部分的管理方式，我不敢保障国内网站以加密的方式保存你的口令。我感到，做为一个有知己的人，我们应该加密保存用户的口令）
是否让浏览器保存口令 。我们有N多的方法可以不让阅读器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决议，重点是看一下你的系统的安全级别是否要求比拟高，如果是的话，则不要让浏览器保存密码，并在网站显明的地位告诉用户——保存口令最安全的处所只有你的大脑。
口令在网上的传输 。因为HTTP是明文协定，所以，用户名和口令在网上也是明文发送的，这个很不平安。你可以看看这篇文章你就清楚了。要做到加密传输就必须使用HTTPS协议。然而，在中国仍是有良多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的起因。我通常懂得为这些ActiveX控件是为了反键盘记载程序的。 不外，我仍然觉ActiveX控件不应当存在，因为在国外的众多保险很主要的站点上都看不到ActiveX的控件的身影。
用户登录状况
首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无奈记载用户访问状态的，其每次恳求都是独破的无关系的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转进程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。
所以，我们每个页面都需要对用户的身份进行认证 。当然，我们不可以让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站想当的SB。为了实现这一功能，用得最多的技巧就是浏览器的cookie，我们会把用户登录的信息存放在客户真个cookie里，这样，我们每个页面都从这个cookie里取得用户是否登录的信息，从而到达记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些准则。
千万不要在cookie中寄存用户的密码 。加密的密码都不行。由于这个密码能够被人获取并尝试离线穷举。所以，你必定不能把用户的密码保留在cookie中。我看到太多的站点这么干了。
准确设计“记住密码” 。这个功能几乎就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。下面是一些方法供你参考。
1）在cookie中，保存三个货色——用户名 ，登录序列 ，登录token 。
用户名 ：明文存放。
登录序列 ：一个被MD5加密过的随机数，每次以输入口令的方式登录后更新。
登录token ：一个被MD5加密过的随机数，仅一个登录session内有效，新的登录session会更新它。
2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。
3）为什么要设计这个样子？因为，
a）登录token 是单实例登录。意思就是一个用户只能有一个实例。
b）登录序列 是用来做盗用行动检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是认为是正当用户，然后更新“登录token ”，而真正的用户访问时系统发现，只有“用户名 ”和“登录序列 ”相同，但是“登录token ” 错误，这样的话，系统就知道，这个用户呈现了被盗用的情形，于是，系统可以肃清登录序列 和 登录token ，这样就可以令所有的cookie生效，并要求用户输入口令。并给忠告用户系统安全。
不要让cookie有权限拜访所有的操作 。否则就是XSS攻击，这个功效请参看新浪微博的XSS攻击。下面的这些功能一定要用户输进口令：
1）修改口令。
2）修正电子邮件。（电子邮件通过用来找回用户密码）
3）用户的隐衷信息。
4）用户花费功能。
找回口令的功能
找回口令的功能一定要提供。但是很多友人并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我一一点评一下。
千万不要使用安全问答 。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的诞辰，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更实在了，我可以上facebook，开心，人人网，LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。Facebook的安全问答很强盛，还要你通过照片认人。
不要重置用户的密码 。因为这有可能让用户的密码受到恶意攻击。当然，你要发个邮件给用户让其确认，用户点击邮件中的一个链接，你再重置。我并不推举这样的方法，因为用户一般都会用笔记下来这个很记的口令，然后登录系统，因为登录系统时使用了“记住密码”的功能，所以导致用户不会去修改密码，从而要么导到被写下来的密码被人盗取，要么又忘却了密码。
好一点的做法——通过邮件自行重置 。当用户申请找回口令功能的时候，系统天生一个MD5独一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，而后设置上时限（比如1小时内），给用户发一个邮件，这个衔接中包括那个MD5的字串的链接，用户通过点击那个链接来自己从新设置新的口令。
更好一点的做法——多重认证 。比如：通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不掌握，因为手机要能会丢了，而我的手机可以访问我的邮箱。所以，使用U盾，SecureID，或是通过人工的方式核适用户身份。当然，这重要看你的系统的安全级别了。
口令探测防守
应用验证码 。验证码是后盾随机发生的一个短暂的验证码，这个验证码个别是一个盘算机很难辨认的图片。这样就可以避免以程序的方式来尝试用户的口令。事实证实，这是最简略也最有效的方式。当然，老是让用户输入那些肉眼都看不清的验证码的用户休会不好，所以，可以折中一下。比方Google，当他发现一个IP地址发出大批的搜寻后，其会请求你输入验证码。当他发明统一个IP注册了3个以上的gmail邮箱后，他须要给你发短信方式或是电话方法的验证码。
用户口令失败次数 。调置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。但是，这个功能可能会被恶意人使用。最好的方法是，增加其尝试的时间成本（以前的这篇文章说过一个增长时间成本的解密算法）。如，两次口令尝试的距离是5秒钟。三次以上错误，帐号被常设锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时……
系统全局防守 。上述的防守只针对某一个别用户。歹意者们深知这一点，所以，他们正常会动用“僵尸网络”轮着尝试一堆用户的口令，所以上述的那种办法可能还不够好。我们需要在体系全局域上监控所有的口令失败的次数。当然，这个需要我们平时不受到袭击时的数据做为支撑。好比你的系统，均匀天天有5000次的口令毛病的事件，那么你可以以为，当口令过错大幅超过这个数后，而且时间绝对集中，就阐明有黑客攻打。这个时候你怎么办？普通最常见使用的方式是让所有的用户输错口令后再次尝试的时光本钱增添。
相关的主题文章：
(责任编辑：网站建设)
你会做用户登录功能吗？_相关文章