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中。我看到太多的站点这么干了。

　　正确设计“记住密码” 。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计 是——一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的方法供你参考：

　　(——更新 2011/08/26，原文中有些小错误，并且说的不清楚，重新调整了一下—— )

　　1)在cookie中，保存三个东西——用户名 ，登录序列 ，登录token 。

　　用户名 ：明文存放。

　　登录序列 ：一个被MD5散列过的随机数，仅当强制用户输入口令时更新(如：用户修改了口令)。

　　登录token ：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。

　　2)上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。

　　3)这样的设计会有什么样的效果，会有下面的效果，

　　a)登录token 是单实例登录。意思就是一个用户只能有一个登录实例。

　　b)登录序列 是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token ”，而真正的用户回来访问时，系统发现只有“用户名 ”和“登录序列 ”相同，但是“登录token ” 不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token ，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。

　　4)当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录 。一个设备会让另一个设备的登录token 和登录序列 失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址，

　　a) 如果以口令方式登录，我们无需更新服务器的“登录序列 ”和 “登录token ”(但需要更新cookie)。因为我们认为口令只有真正的用户知道。

　　b) 如果IP相同 ，那么，我们无需更新服务器的“登录序列 ”和 “登录token ”(但需要更新cookie)。因为我们认为是同一用户有同一IP(当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能)。

　　c) 如果 (IP不同 &&没有用口令登录 )，那么，“登录token ” 就会在多个IP间发生变化(登录token在两个或多个ip间被来来回回的变换)，当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列 ”和“登录token “，让Cookie失效，强制用户输入口令(或是要求用户更改口令)，以保证多台设备上的cookie一致。

　　不要让cookie有权限访问所有的操作 。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令：

　　1)修改口令。

　　2)修改电子邮件。(电子邮件通过用来找回用户密码)

　　3)用户的隐私信息。

　　4)用户消费功能。

　　权衡Cookie的过期时间。 如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。

　　找回口令的功能

　　找回口令的功能一定要提供。但是很多朋友并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我逐个点评一下。

　　千万不要使用安全问答 。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，