首页 > Web开发, 程序设计, 网络安全 > 你会做Web上的用户登录功能吗?

你会做Web上的用户登录功能吗?

2011年8月25日 发表评论 阅读评论 60,182 人阅读    

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的过期时间我们还需要权衡。

找回口令的功能

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

  • 千万不要使用安全问答。事实证明,这个环节很烦人,而且用户并不能很好的设置安全问答。什么,我的生日啊,我母亲的生日,等等。因为今天的互联网和以前不一样了,因为SNS,今天的互联比以前更真实了,我可以上facebook,开心,人人网,LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。 这里需要说一下 Facebook,Facebook的安全问答很强大,还要你通过照片认人,呵呵。
  • 不要重置用户的密码。因为这有可能让用户的密码遭到恶意攻击。当然,你要发个邮件给用户让其确认,用户点击邮件中的一个链接,你再重置。我并不推荐这样的方法,因为用户一般都会用笔记下来这个很难记的口令,然后登录系统,因为登录系统时使用了“记住密码”的功能,所以导致用户不会去修改密码,从而要么导到被写下来的密码被人盗取,要么又忘记了密码。
  • 好一点的做法——通过邮件自行重置。当用户申请找回口令功能的时候,系统生成一个MD5唯一的随机字串(可通过UID+IP+timestamp+随机数),放在数据库中,然后设置上时限(比如1小时内),给用户发一个邮件,这个连接中包含那个MD5的字串的链接,用户通过点击那个链接来自己重新设置新的口令。
  • 更好一点的做法——多重认证。比如:通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不把握,因为手机要能会丢了,而我的手机可以访问我的邮箱。所以,使用U盾,SecureID(一个会变化的6位数token),或是通过人工的方式核实用户身份。当然,这主要看你的系统的安全级别了。

口令探测防守

  • 使用验证码。验证码是后台随机产生的一个短暂的验证码,这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。事实证明,这是最简单也最有效的方式。当然,总是让用户输入那些肉眼都看不清的验证码的用户体验不好,所以,可以折中一下。比如Google,当他发现一个IP地址发出大量的搜索后,其会要求你输入验证码。当他发现同一个IP注册了3个以上的gmail邮箱后,他需要给你发短信方式或是电话方式的验证码。
  • 用户口令失败次数。调置口令失败的上限,如果失败过多,则把帐号锁了,需要用户以找回口令的方式来重新激活帐号。但是,这个功能可能会被恶意人使用。最好的方法是,增加其尝试的时间成本(以前的这篇文章说过一个增加时间成本的解密算法)。如,两次口令尝试的间隔是5秒钟。三次以上错误,帐号被临时锁上30秒,5次以上帐号被锁1分钟,10次以上错误帐号被锁4小时……但是这会导致恶意用户用脚本来攻击,所以最好再加上验证码,验证码出错次数过多不禁止登录而是禁lP。
  • 系统全局防守。上述的防守只针对某一个别用户。恶意者们深知这一点,所以,他们一般会动用“僵尸网络”轮着尝试一堆用户的口令,所以上述的那种方法可能还不够好。我们需要在系统全局域上监控所有的口令失败的次数。当然,这个需要我们平时没有受到攻击时的数据做为支持。比如你的系统,平均每天有5000次的口令错误的事件,那么你可以认为,当口令错误大幅超过这个数后,而且时间相对集中,就说明有黑客攻击。这个时候你怎么办?一般最常见使用的方法是让所有的用户输错口令后再次尝试的时间成本增加。
最后,再说一下,关于用户登录,使用第三方的 OAuth 和 OpenID 也不失为一个很不错的选择。

参考文章

以上内容,转载时请保持原文一致,并请注明作者和出处

(转载本站文章请注明作者和出处 酷 壳 – CoolShell.cn ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (38 人打了分,平均分: 4.79 )
Loading...Loading...
  1. robin
    2011年12月21日23:27 | #1

    里面说active控件那个没说清楚。
    先说用HTTPS,然后用但是。。这里是说activex不能走SSL?
    另外说什么国外很多网站不用activex。
    太绕了,不如直接把activex为什么不够安全的地方说出来。

  2. 2011年12月22日14:08 | #2

    其实登录token没有必要进行散列运算,直接用随机数字就行了

  3. 2011年12月24日20:48 | #3

    不同意文中一些观点. 当然, 像存储密码hash值, https加密这些是常识. 但是 ‘正确设计“记住密码”’这条可能对用户造成困扰, 我就经常频繁切换多IP(代理服务器/VPN), 多浏览器, 多设备登录同一网站 = =, 或者用lynx或curl使用保存的cookie做一些自动化任务 = =, 所以登录token单实例毫无必要, 合法用户也可能这样做. “Cookie有效期” 更是很烦人的东西, 这个应该交给用户去选择有效期是”永久”还是一定期限. 最令我郁闷的是很多网站即使登录时设为”永久有效”过一段时间再去还得重新登录, 即使有Lastpass也非常烦人. 像淘宝, 亚马逊,Paypal, 网银之类网站根本无法保存session, 关掉浏览器就得重输密码, 非常非常令我讨厌, 我不管你这个网站需要多高的安全性, 你至少应该给用户选择权利.

    有一点我很同意就是”千万不要使用安全问答”, 安全问答这玩意就是给别人社会工程用的, 俺所有网站注册时如果要填安全问答一律写N位随机字符 = =

  4. 2011年12月28日00:28 | #5

    @小野大神
    cookie保存时间是有个上线的,不可能永久存放的…

  5. sunshine1988
    2011年12月29日15:22 | #6

    @小野大神
    不要期待cookie永久保存,cookie是放在浏览器的,很多不可控的情况可以将之清除而不一定是该网站没有存储足够长的时间~~

  6. 幻の上帝
    2011年12月30日18:29 | #7

    实用上,口令的密级应该和需要保密的信息安全程度相关(一刀切就整个不安全了),于是限制口令会增加用户在使用方面(评估风险、增加较强口令使用频率等等)的负担。既然拒绝用户使用足够弱的口令,用户自然可能质疑网站凭什么资格要求自己在这个网站上启用强口令。实际上这种对用户管理口令能力的不信任就是把问题弄复杂了,谁都没什么好处。

  7. BennyTian
    2012年1月13日12:39 | #9

    是不是还需要在用户输入密码之前给用户计算机做个全盘扫描呢.查杀下有木病毒~~~

    可笑.

    简单的东西复杂化就是牛B的体现么?

    也得先看看你是什么个系统,别什么登录都搞得银行一样:发个U盾 或者加密狗什么的….

  8. any
    2012年1月13日15:14 | #10

    楼主,你这个用户名 登录序列 登录token的模型,没有看明白,他们三者的定义可否贴出下。

  9. any
    2012年1月13日15:15 | #11

    这个是什么意思?我们无需更新服务器的“登录序列”和 “登录token”(但需要更新cookie),cookie改了,和服务端对不上了。怎么还能登陆成功?

  10. wocao
    2012年1月14日21:42 | #12

    真希望各位认真思考后再发表评论

  11. null
    2012年3月7日18:40 | #13

    OpenID.net上显示的provider没有中国网站。
    那么腾讯、支付宝等公司的统一登录,是不是实际上不支持OpenID?而是自己自己模仿OpenID的理念做的平台?

  12. BlueDream
    2012年3月21日15:05 | #14

    问一下
    登录token:一个被MD5散列过的随机数,仅一个登录session内有效,新的登录session会更新它

    这句话怎么理解?如果我的cookie被盗了,那么对方不也是得到同样的session了。那么就不会有新的登录session了呀

  13. hijude
    2012年7月31日13:58 | #15

    写得很不错,什么时候能写一篇“你会做Web上的用户注册功能吗?”

  14. Tanidea
    2012年9月15日11:07 | #16

    MikeZh :
    如果cookie被盗用,而本人不再使用呢?是不是应该在不同ip而相同cookie情况下清空cookie,让用户重输密码呢?

    这个想得周到

  15. bloodybird
    2012年10月3日04:17 | #17

    我有一点疑惑,文章中提到,“在cookie中,保存三个东西——用户名,登录序列,登录token”,“如果用户的cookie被盗后,盗用者使用这个cookie访问网站时,我们的系统是以为是合法用户,然后更新“登录token”,…”,难道用户(或盗用者)每次访问网站都更新登录token?显然这里的访问应该写成登录更合适。但,盗用cookie目的是绕过登录过程,直接以已登录的状态进行用户操作,这样一改又与上下文有出入。

  16. 2012年12月24日03:42 | #18

    @BennyTian
    这种说法就不对了。

  17. 2012年12月24日03:44 | #19

    @any
    如果确实不懂的话,可以去看看cookies的相关资料,以及具体看一些demo,了解一些网站的登陆流程。其实博主已经说得很清晰了。

  18. onlinetalk
    2013年2月28日10:25 | #20

    唉,真得很烂;水平也太菜了~

  19. Dlad
    2013年2月28日10:58 | #21

    互斥登陆的功能实现,有一点不太明白:
    由3.b得出,登陆序列可以用来实现自动登录。
    若用户选择自动登陆,单纯更新登陆token是无法实现互斥登陆的。

  20. 围炉闲扯
    2013年4月28日16:56 | #22

    有个地方没看懂:
    登录序列是用来做盗用行为检测的。如果用户的cookie被盗后,盗用者使用这个cookie访问网站时,我们的系统是以为是合法用户,然后更新“登录token”,而真正的用户回来访问时,系统发现只有“用户名”和“登录序列”相同,但是“登录token” 不对。
    ——这地方,cookie被盗,看着是“copy”而不是“cut”。把cookie拿走让用户重新登录重新获取token不可以吗?就当多终端了。

  21. 2013年6月3日14:05 | #23

    打算使用php写一个注册/登录的小demo,一直在考虑怎么验证用户的登录状态。
    想问一下,单单使用session不使用cookie是否可以?有什么缺陷?

  22. 2013年8月4日11:16 | #24

    [The definitive guide to forms based website authentication](http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication#477579) 所有的问题和回答都可以在这篇帖子上看到。超级有意思的一个帖子,回答基本都是长篇博文了[/偷笑]

  23. 2013年8月4日11:17 | #25

    标题说明了一切[/偷笑]@arganzheng

  24. Navy
    2013年8月28日00:25 | #26

    @小野大神
    有时候系统设计必须有一些原则,例如安全有限原则或性能优先原则等。
    看见你的评论,你应该是个高手,当大多数可能只是一般的使用者,对应对安全性高的系统来说,有些时候是需要牺牲一点可用性来保障安全性。
    个人见解。

评论分页
1 2 5353
  1. 2011年8月25日18:11 | #1
  2. 2011年8月26日01:26 | #2
  3. 2011年8月26日20:12 | #3
  4. 2011年9月10日11:55 | #4
  5. 2011年12月21日23:32 | #5
  6. 2011年12月21日23:41 | #6
  7. 2011年12月22日12:08 | #7
  8. 2011年12月22日16:10 | #8
  9. 2011年12月22日17:09 | #9
  10. 2011年12月23日11:50 | #10
  11. 2011年12月23日17:27 | #11
  12. 2011年12月23日21:58 | #12
  13. 2011年12月25日01:02 | #13
  14. 2011年12月25日14:20 | #14
  15. 2011年12月28日10:07 | #15
  16. 2012年4月11日13:15 | #16
  17. 2012年4月18日00:34 | #17
  18. 2012年9月15日10:01 | #18
  19. 2012年12月11日00:34 | #19
  20. 2012年12月25日19:07 | #20
  21. 2013年1月28日03:31 | #21
  22. 2013年3月15日09:14 | #22
  23. 2013年5月19日14:13 | #23
  24. 2013年8月24日19:24 | #24
  25. 2013年8月31日17:33 | #25
  26. 2013年9月1日15:55 | #26
  27. 2013年10月27日15:20 | #27
  28. 2013年11月16日16:07 | #28
  29. 2014年2月10日14:02 | #29
  30. 2014年3月31日17:13 | #30