认证与会话管理

简介
很多时候，人们会把“认证”和“授权”两个概念搞混，实际上“认证”和“授权”是两件事。认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。
认证的手段是多样化的，目前认证方式有密码、数字证书、手机绑定、指纹、人脸、声音等认证。认证实际上就是一个验证凭证的过程。如果只有一个凭证被用户认证，则称为“单因素认证”；如果有两个或多个凭证被用户认证，则成为“双因素认证”或“多因素认证”。一般来说，多因素认证的强度要高于单因素认证，但是在用户体验上，多因素认证或多或少都会带来一些不方便的地方。

密码认证
密码是最常见的一种认证手段，但目前并没有一个标准的密码策略，根据OWASP推荐的一些最佳实践，以下是对密码策略的总结。
密码长度方面：
1)普通应用要求长度为6位以上；
2)重要应用要求长度为8位以上，并考虑双因素认证。
密码复杂度方面：
1)密码区分大小写字母；
2)密码为大写字母、小写字母、数字和特殊字符中两种以上的组合；
3)不要有连续性的字符，比如1234abcd，这种字符容易被猜测到；
4)尽量避免出现重复的字符，如1111.。
关于密码的保存也有一些需要注意的地方。一般来说，密码必须以不可逆的加密算法，或者是单向散列函数算法，加密后存储在数据库中。这样即使黑客入侵了网站，导出数据库中的数据，也无法获取到密码的明文。
将明文密码经过哈希后在保存到数据库中，是目前业界比较普遍的做法，在用户注册是就已将密码哈希后保存在数据库中，登录时验证密码的过程仅仅是验证用户提交的密码哈希值，与保存在数据库中的密码哈希值是否一致。
目前黑客们广泛使用的破解MD5后密码的方法是“彩虹表”。彩虹表的思路是收集尽可能多的密码明文和明文对应的MD5值。这样只需要查询MD5值，就能找到该MD5值对应的明文。彩虹表的简历，还可以周期性的计算一些数据的MD5值，以扩种彩虹表的内容。
为了防御彩虹表一类的攻击，通常的做法是Salt加密，即在计算密码明文的哈希值时，增加一个随意字符串Salt。

Session认证
密码与证书等认证手段，一般仅仅是用于登录的过程。当登录完成后，用户访问网站的页面，不可能每次浏览器请求页面时都使用密码认证一次。因此，当认证成功后，就需要替换一个对用户透明的凭证。这个凭证，就是SessionID。用户在登录完成后，服务器端会创建一个新的会话Session。
SessionID保存在Cookie中
一般常见的做法是把Session保存在Cookie中。而Cookie泄露的途径有很多种，如XSS攻击、网络监听以及本地木马窃取。对于通过XSS泄露窃取Cookie的攻击，通过给Cookie标记httponly，可以有效的缓解XSS窃取Cookie的问题。
SessionID作为请求参数
在手机操作系统中，由于很多手机浏览器暂不支持Cookie，所以只能把SessionID作为URL的一个参数用户认证。这种情况下可以通过Referer泄露URL中的sid。QQ的WAP邮箱曾经出现过此漏洞，如下。
1)攻击者发送给用户一张外部网络的图片：
2)用户用手机浏览器打开QQ邮箱时，实际上发起了一次GET请求，这个请求会带上Referer。Referer的值为：
http://w34.mail.qq.com/cgi-bin/readmail?sid=xxxx&....
3)攻击者可以通过自己服务器的日志查看并获取Referer从而获取sid。

Session Fixation攻击
用户在登录网站的过程中，如果登陆前后用户的SessionID没有发生变化，则会存在Session Fixation攻击。
具体的攻击过程是，用户X（攻击者）先获取一个未经认证的SessionID，然后将这个SessionID交给用户Y去认证，Y完成认证后，服务器并未更新此SessioniID的值，所以之后X可以凭借此SessionID登录进Y的账户。这种攻击一般是在SessionID作为URL的一个参数的情况。
解决Session Fixation的正确做法是，在登录完成后，重写SessionID。

Session保持攻击
一般应用都会给Session设置一个失效时间，当到达失效时间后，Session将被销毁。但有些系统，处于用户体验的考虑，只要这个用户还“活着”，就不会让这个用户的Session失效。此时，如果攻击者已经获取一个有效的SessionID，则可以通过不停地发起访问请求，让Session一直“活”下去。
防御Session保持攻击的方法有：
1)在一定的时间强制销毁Session。这个时间可以从用户登录的时间算起，设定一个阈值，比如3天后强制Session过期。
2)当用户客户端发生变化时，要求用户重新登录。如用户的IP、UserAgent等信息发生了变化，就可以强制销毁当前的Session，并要求用户重新登录。