基于表单认证本身是通过服务器端的web应用，将客户端发送的用户id和密码与之前登录过的信息做匹配来进行认证的。但鉴于HTTP 是无状态的，之前已认证过的用户无法通过协议层面保存下来。当该用户下一次访问时，无法区分它和其它用户。于是会使用Cookie来管理Session,以弥补HTTP协议中不存在的状态管理功能。                                                                                           
                                                      
步骤1：客户端把用户Id和密码等登陆信息放入报文的实体部分，通常以POST 方法把请求发送给服务器。而这时会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。

步骤2： 服务器会发放用以识别用户的SessionID。通过验证从客户端发送过来的登录信息进行身份验证，然后把用户的认证状态与Session ID 绑定后记录在服务器端。
向客户端返回响应时，会在首部字段Set-Cookie内写入Sesiion ID（如***=82438sd....)。我们可以把Session ID 想象成一种用于区分不同用户的等位号，然而如果Session ID 被第三方盗走，对方就会伪装成你的身份进行恶意操作。因此必须防止Session ID 被盗，为了做到这点，Session ID 应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。另外为了减轻脚本攻击（XSS)造成的损失，建议事先在Cookie 内加上httponly 属性。

步骤3：客户端收到从服务器端发来的Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID 也会随之发送到服务器。服务器端可通过验证接收到的Session ID 识别用户及其认证状态。

        另外不仅基于表单验证的登录信息及认证过程无标准化的方法，服务器端应该如何保存用户提交的密码等登录信息等也没有标准化。通常，一种安全的饿保存方法是先利用给密码加盐（salt)的方式增加额外信息，再使用散列（hash)函数计算出散列值后保存。但我们也经常看到直接保存明文密码的做法，这样做具有导致密码泄露的风险。

备注：salt 其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串相连接（前后均可）生成散列值。当两个用户使用了同一个密码时，由于随机生成的salt值不同，对应的散列值也将是不同的。这样一来，很大程度上减少密码特征，攻击者也就很难利用自己手中的密码特征库进行破解。

      基于表单认证本身是通过服务器端的web应用，将客户端发送的用户id和密码与之前登录过的信息做匹配来进行认证的。但鉴于HTTP 是无状态的，之前已认证过的用户无法通过协议层面保存下来。当该用户下一次访问时，无法区分它和其它用户。于是会使用Cookie来管理Session,以弥补HTTP协议中不存在的状态管理功能。                                                                                           
                                                      
步骤1：客户端把用户Id和密码等登陆信息放入报文的实体部分，通常以POST 方法把请求发送给服务器。而这时会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。

步骤2： 服务器会发放用以识别用户的SessionID。通过验证从客户端发送过来的登录信息进行身份验证，然后把用户的认证状态与Session ID 绑定后记录在服务器端。
向客户端返回响应时，会在首部字段Set-Cookie内写入Sesiion ID（如***=82438sd....)。我们可以把Session ID 想象成一种用于区分不同用户的等位号，然而如果Session ID 被第三方盗走，对方就会伪装成你的身份进行恶意操作。因此必须防止Session ID 被盗，为了做到这点，Session ID 应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。另外为了减轻脚本攻击（XSS)造成的损失，建议事先在Cookie 内加上httponly 属性。

步骤3：客户端收到从服务器端发来的Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID 也会随之发送到服务器。服务器端可通过验证接收到的Session ID 识别用户及其认证状态。

        另外不仅基于表单验证的登录信息及认证过程无标准化的方法，服务器端应该如何保存用户提交的密码等登录信息等也没有标准化。通常，一种安全的饿保存方法是先利用给密码加盐（salt)的方式增加额外信息，再使用散列（hash)函数计算出散列值后保存。但我们也经常看到直接保存明文密码的做法，这样做具有导致密码泄露的风险。

备注：salt 其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串相连接（前后均可）生成散列值。当两个用户使用了同一个密码时，由于随机生成的salt值不同，对应的散列值也将是不同的。这样一来，很大程度上减少密码特征，攻击者也就很难利用自己手中的密码特征库进行破解。