介绍Basic和Digest

Http Basic Digest 认证

汇总几篇讲http basic 和 digest的文章。

1. 基本原理介绍

• Basic and Digest Access Authentication (rfc2617) 及HttpClient实现: http://www.cnblogs.com/jcli/archive/2012/12/11/2812459.html。 该文介绍了Basic和Digest认证的基本流程和http认证与https的关系（他们没有关系）
  
• nonce和timestamp在Http安全协议中的作用: http://www.cnblogs.com/bestzrz/archive/2011/09/03/2164620.html。看标题就知道该文讲什么了。

2. 相关实验

• http认证(一) - Basic 认证： http://robblog.iteye.com/blog/554450。该文讲解了如何在Tomcat中配置Basic认证以及如何用Firebug来查看Basic认证的Request和Response
• http认证(二) - DIGEST 认证： http://robblog.iteye.com/blog/556436。该文讲解了如何在Tomcat中配置Digest认证以及如何用Firebug来查看Digest认证的Request和Response

需要注意的是：上面两篇文章中的web.xml配置有一点问题，漏掉了在web.xml配置security-role这个节点。请参阅这篇文章：http://www.thecoderscorner.com/team-blog/16-hosting-servers/17-setting-up-role-based-security-in-tomcat#.UPfKH6PQNh8里面有完整的web.xml的例子。

 

 

 

介绍Basic和Digest

http协议并没有定义相关的安全认证方面的标准，所以就有了Basic and Digest Access Authentication的定义来补充，它的目的就是补充一套基于http服务端的认证机制，保护相关的资源避免被非法用户访问,如果你要访问被保护的资源，则必需要提供合法的用户名和密码。

和https有什么关联？

basic & digest auth 和 https 没有任何关系。前者是为用户认证机制，后者是信息通道加密措施。

basic 和 digest有什么区别？

digest是basic的升级版，更加安全。因为basic是明文传输密码信息，而digest是加密后传输。

digest就是绝对安全的吗？

首先，这个世界上没有绝对的东西。digest默认用MD5（其它算法也可以）对密码进行加密，虽然相比basic认证的明文传输更安全，但是加密算法本身的安全性也值得怀疑(md5是可以反推出原文的)。再者，digest只是对认证信息的加密，后续的内容传输安全性得不到保障。所以https机制的作用就显现出来。

通过上面的相关信息，我们可以得到一个清晰的结论：如果你想加强自己的认证信息的保护，有两种选择，一是基于digest认证；别一种是在https通道上进行basic认证。

basic和digest认证流程

1，客户端请求受保护的资源
2，服务器检测到没有授权，则生成一个challenge返回给客户端
3，客户端根据challenge和相关信息计算出digest
4，附带3计算出的信息再次请求1中的资源
5，服务端根据已知的用户密码信息计算出digest并与4中请求的digest比较验证
6，服务端验证通过后返回资源给合法用户

Basic和Digest的认证都是按照上面的流程来，唯一不同的是3和5中计算digest的算法不同：Basic是将密码直接base64编码(明文),而Digest是用MD5进行加密后传输。

下面假设我们现在要请求：http://localhost:8080/index.html 这个路径，而它需要认证后才能访问。

Basic的流程如下：

1. 在浏览器请求：http://localhost:8080/index.html
2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头，格式如下：WWW-Authenticate    Basic realm="Admin All"
3. 浏览器用：base64(username:password) 编码后的信息添加到请求头中再次请求1中的资源，如果用户名是tomcat,密码是tomcat,则base64(tomcat:tomcat)为（dG9tY2F0OnRvbWNhdA==）。所以头信息为：Authorization    Basic dG9tY2F0OnRvbWNhdA==
4. 用3中计算的请求头信息再次请求1中的资源
5. 服务器用3中相同的算法(base64)验证用户密码合法性
6. 返回index.html的资源

Digest的流程和上面一样，只是challenge和digest的生成算法不同

1. 在浏览器请求：http://localhost:8080/index.html
2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头，格式如下：WWW-Authenticate    Digest realm="Admin All", qop="auth", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", opaque="EE9C283E89AFB63E7FF6E2C04C524807"
3. 浏 览器用MD5编码后的信息添加到请求头中再次请求1中的资源，如果用户名是tomcat,密码是tomcat,则生成的头信息:Authorization    Digest username="tomcat", realm="Admin All", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", uri="/web/index.html", response="8d30e6438636fe21c6045246dd034372", opaque="EE9C283E89AFB63E7FF6E2C04C524807", qop=auth, nc=00000001, cnonce="9201a828891792b9"
4. 用3中计算的请求头信息再次请求1中的资源
5. 服务器用3中相同的算法(base64)验证用户密码合法性
6. 返回index.html的资源

这里我们只是讨论流程，具体的challenge和digest的生成算法请参考：RFC2617