第9章 认证与会话管理

9.1 who am i?

认证包含了身份和身份认证两层含义。

q  身份—我是谁？

q  身份认证—这就是我。

认证的目的就是为了认出用户是谁？而授权的目的是为了决定用户能够做什么。

认证实际上就是一个验证凭证的过程。

9.2 密码的那些事儿

一般为了安全与用户体验性，采用“双因素”验证的比较多，例如支付中的密码和手机动态密钥。

我认为在用户注册的时候应该检测一下用户使用的是否是弱密码。这就代表着我们需要在系统中建立一套“弱密码表”，弱密码表如下。

注：上述弱密码已经经过SHA1加密，原文与密文以“;”分割

密码尽可能的使用单向加密算法或者md5

9.3 多因素认证

除了一般的密码之外，动态口令，数字证书，U盾，第三方证书等都是可用于用户认证的。这些不同的手段可以相互结合，使得认证的过程更加安全可靠。密码不再是唯一的认证手段，在用户密码失窃的情况下，仍可保障用户账户的安全。

9.4 session与认证

Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存息。

但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为 Session id，如果已经包含一个Session id则说明以前已经为此客户创建过Session，服务器就按照Session id把这个Session检索出来使用（如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为地在请求的URL后面附加上一个JSESSION的参数）。如果客户请求不包含Session id，则为此客户创建一个Session并且同时生成一个与此Session相关联的Session id，这个Session id将在本次响应中返回给客户端保存。

保存Session  id的几种方式:

q  保存Session id的方式可以采用Cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。

q  由于Cookie可以被人为的禁止，必须有其它的机制以便在Cookie被禁止时仍然能够把Session id传递回服务器，经常采用的一种技术叫做URL重写，就是把Session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个Session id。

q  另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把Session id传递回服务器。

9.5 session fixation攻击

防范SessionFixation攻击:用户认证后一定要变换SessionID。随机算法需要足够强大。

9.6 session保持攻击

防范Session保持攻击：

在一定的时间或特定的条件强制注销Session。如发出的Session的IP或者UserAgernt或者地点或者多个Session的情况时候。

9.7 单点登录（sso）

对于单点登录的一下缺陷，可以在指定的系统应用中加“双因素”验证。

参考：http://dotnet.blog.51cto.com/272325/51559/