某些Web页面只想让特定的人浏览,或者干脆仅本人可见。未达到这个目的,必不可少的就是认证功能。
服务端为了验证客户端登陆者的身份,该用户是否真的具有访问系统的权限,就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。
核对的信息通常是指以下这些:
HTTP使用的认证方式:
基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息,按登录信息的验证结果认证。
多数情况下,输入已经事先登录的用户ID和密码等用户信息,发送给Web应用程序,基于认证结果来决定是否成功。
由于使用上的便利性 及安全性问题,HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。另外,SSL客户端认证虽然具有高度的安全等级,但因为导入及维持费用等问题,还尚未普及。
SSH和FTP协议,服务器与客户端之间的认证是合乎标准规范的,并且满足了最基本的功能从需求上的安全级别,因此这些协议的认证可以拿来直接使用。
但是由于Web网站的认证功能,能够满足其安全使用级别的标准规范并不存在,所以只好使用由Web应用程序各自实现基于表单的认证方式。
基于表单认证的标准规范尚未有定论,一般会使用Cookie来管理Session。
基于表单认证本身是通过服务器的Web应用,将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证。
但鉴于HTTP是无状态协议,之前已经认证成功的用户状态无法通过协议层面保存下来。即,无法实现状态管理,因此即使当该用户下一次继续访问,也无法区分他与其他用户。于是我们使用Cookie管理Session,以弥补HTTP协议中不存在的状态管理功能。
另外,不仅基于表单认证的登录信息及认证过程无标准化的方法,服务器端应如何保存用户提交的密码及登录信息也没有标准化。
通常,一种安全的保存方法是,先利用给密码加盐的方式增加额外信息,再使用散列函数计算出散列值后保存。
BASIC认证(基本认证)是从HTTP1.0就定义的方式。
BASIC认证虽然采用Base64编码方式,但这不是加密处理。不需要任何附加信息即可对其解码。换言之,由于明文解码后就是用户ID和密码,在HTTP等非加密通信的线路上进行BASIC的认证,如果被别人窃听,被盗的可能性极高。
1.使用上不灵活;2.安全等级不高,因此并不常用。
为了弥补BASIC认证存在的弱点,从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式,但不会像BASIC认证那样直接发明文密码。
1.使用上不灵活;2.安全等级不高,虽然高于BASIC,因此并不常用。
如果用户的ID和密码被盗,就很有可能被第三方冒充。利用SSL客户端认证则可以避免该情况的发生。
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式,凭借客户端证书认证,客户端来确认访问是否来自己登陆客户端。
未达到SSL客户端认证的目的,需要事将客户端证书分给客户端,且客户端必须安装此证书。
多数情况下,客户端认证不会仅依靠证书完成认证,一般会和表单认证组成双因素认证。
第一个认证因素的SSL客户端证书用来认证客户端计算机,另一个认证因素的密码则用来确定这是用户本人的行为。
通过双因素认证后,就可以确定是用户本人正在使用匹配正确的计算机访问服务器。