表单认证详解-优快云博客

基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的web应用程序发信息（Credential），按登录信息的验证结果认证。

根据web应用程序的实际安装，提供用户界面认证方式也各有不同

多数情况下，输入已事先登录的用户ID（通常是任意字符串或邮箱地址）和密码等登录信息后，发送web应用程序，基于认证结果来确定认证是否成功

认证多半为基于表单认证

由于使用上的便利性及安全性问题，http协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用，另外，SSL客户端认证虽然具有高度的安全等级，但因为导入及维护费用等问题，还尚未普及。

比如SSH和FTP协议，服务器与客户端之间的认证时合乎标准规范的，并满足了最基本的功能需求上的安全使用级别，因此这些协议的认证可以拿来直接使用。但是对于web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只要使用web应用程序各自实现基于表单的认证方式。

不具备共同标准规范的表单认证，在每个web网站上都会有各自不同的实现方式。如果是全面考虑过安全性能而实现的表单认证，那么就能够具备高度的安全等级。但在表单认证中存在问题的Web网站也是屡见不鲜。

session管理及cookie应用

基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session（回话）

基于表单认证本身是通过服务器端的web应用，将客户端发送过来的用户ID和密码与之前的登录过的先做匹配进行认证的。

但鉴于http是无状态协议，之前认证成功的用户状态无法通过协议层面保存下来。既，无法实现管理状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们就是要cookie来管理session，以弥补http协议中不存在的状态管理功能。

步骤1 ：客户端把用户ID和密码等登录信息放入报文的实体部分，通常以POST方法把请求发送给服务器，而这时，会使用https通信来进行html表单画面的显示和用户输入数据的发送。

步骤2：服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器.

客户端返回响应时，会在首部字段Set-Cookie 内写入Session ID。

你可以把SessionID想象成一种用以区分不同用户的等位号。

然而，如果Session ID被第三方盗走，对方就可以伪装成你的身份进行恶意的操作。因此必须防止Session ID被盗，或被猜出，为了做到这点，Session ID应使用难以推测的字符串，并服务器也需要进行有效期的管理，保证安全性。

另外，为了减轻跨站脚本攻击（XSS）造成的损失，建议事先在cookie内加上httponly属性。

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

除了以上简介的应用实例，还有应用其他不同方法案例

通常，一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，在使用散列（hash）函数计算散列值后保存。但是我们经常看到直接保存明文密码的做法，这样的做法具有导致密码泄露的风险。

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

frombase认证