HTTP 摘要认证

Basic认证方式是存在很多缺陷的，具体表现如下：
1， Basic认证会通过网络发送用户名和密码，并且是以base64的方式对用户名和密码进行简单的编码后发送的，而base64编码本身非常容易被解码，所以经过base64编码的密码实际上是明文发送的。

2， 即使密码是经过加密传输的，当第三方用户仍然可以捕获被修改过的用户名和密码，并将修改过的用户名和密码反复多次的重放给原始服务器，以获得对服务器的访问权，Basic认证没有什么措施可以用来防止这些重放攻击。

3， 一些不良习惯会使得Basic认证更加危险，那就是用户由于受不了大量密码保护的服务，会在这些不同的服务间使用相同的用户名和密码。

4， Basic认证没有提供任何针对代理和作为中间人的中间节点的防护措施，它们没有修改认证首部，但却能够修改报文的其余部分，这样就严重的改变了事务的本质。即Basic认证没法支持对内容或者报文本身的保护。

5， Basic不支持对称认证，即客户端无法认证服务器的合法性，因此客户端很容易被钓鱼到一个非法的服务器从而输入了用户名和密码。

综上，Basic 认证存在很多的不足，使得一般只能用在一些非常简单场景而不能很好的支持真正的产品级别的运用。

下面要介绍的另外一种认证，摘要认证则针对Basic认证存在的诸多问题而进行的改良方案。

摘要认证时另外一种HTTP认证协议，它试图修复Basci认证的严重缺陷，即进行如下改进:

1， 通过传递用户名，密码等计算出来的摘要来解决明文方式在网络上发送密码的问题。

2， 通过服务产生随机数nonce的方式可以防止恶意用户捕获并重放认证的握手过程。

3， 通过客户端产生随机数cnonce的方式，支持客户端对服务器的认证。

4， 通过对内容也加入摘要计算的方式，可以有选择的防止对报文内容的篡改。

但是，摘要认证并不是罪安全的协议，也无法满足安全HTTP事务的很多需求，对这些需求来说，可能使用HTTPS方式更为合适。

一，用摘要保护密码

摘要认证的一个改进之处是用摘要代替密码的传输，遵循的基本原则是“绝对不通过网络发送明文密码”，而是发送一个密码的摘要信息，并且这摘要信息是不可逆的，即无法通 过摘要信息反推出密码信息。而服务器本身是存储这个密码的（实际上，服务器只需知道密码的摘要即可），而客户端和服务器本身都知道这个密码。这样的话，服务器可以读取客户端的摘要和本身知道的密码进行同样计算得出的摘要进行比较，若匹配，则验证通过。

摘要是对信息主体的浓缩，摘要是一种单向函数，主要用于将无限的输入值转为有限的浓缩输出值，如MD5，则是将任意长度的字节系列转换为一个128位的摘要。MD5输出的128位的摘要通常会写出32个十六进制的字符，每个字符表示4个bit。

二，用随机数防止重放攻击

使用单向摘要就无需以明文形式发送密码了，可以只发送密码的摘要，并且可以确信，没有哪个恶意用户能轻易的从摘要中解码出原始密码。

但是，摘要被截获也可能跟密码一起好用，为了防止重放攻击的发送，服务器可以向客户端发送一个称为随机数nonce的特殊令牌，这个数会经常发生变化(可能是每毫秒，或者每次认证都发生变化，具体由服务器控制)，客户端在计算摘要之前要先将这个随机数附加到密码上去。这样，在密码中加入随机数就会使得摘要随着随机数的每次变化而变化，记录下的密码摘要只对特定的随机数有效，而没有密码的话，攻击者就无法计算出正确的摘要，这样就可以防止重放攻击的发生。

摘要认证要求使用随机数，随机数是在WWW-Authenticate服务器质询响应中从服务器传输给客户端的。

三，摘要认证的原理。

摘要访问认证最初由
RFC 2069 (HTTP的一个扩展：摘要访问认证)中被定义。RFC 2069 大致定义了一个传统的由服务器生成随机数来维护安全性的摘要认证架构。认证响应由下列组成（HA1、HA2、A1、及A2为字符串变量的名称）：







RFC 2069 随后被

RFC 2617 (HTTP 认证：基本及摘要访问认证)。RFC 2617 引入了一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数。这些增强为了防止如选择明文攻击的密码分析。



如果 qop 值为“auth”或未指定，那么 HA2 为



如果 qop 值为“auth-int”，那么 HA2 为



如果 qop 值为“auth”或“auth-int”，那么如下计算 response：



如果 qop 未指定，那么如下计算 response：



上面所述的这种当 qop 未指定的情况，也就是遵循简化的
RFC 2069 标准。

MD5 安全问题对摘要认证的影响

在 HTTP 摘要认证中使用 MD5 加密是为了达成"不可逆的"，也就是说，当输出已知的时候，确定原始的输入应该是相当困难的。如果密码本身太过简单，也许可以通过尝试所有可能的输入来找到对应的输出（穷举攻击），甚至可以通过字典或者适当的查找表加快查找速度。

HTTP 构架由Phillip Hallam-Baker于1993年在CERN设计成的，并且没有吸收后续认证系统的改进，如基于密钥的哈希消息认证代码HMAC的发展。虽然所使用的密码结构是基于MD5哈希函数的，在2004年，通常认为冲突攻击不会影响明文（如密码）未被得知的应用。[1][来源请求]
但是，在2006年的声明 (Kim, Biryukov2, Preneel, Hong,
"On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") 导致了一些包括关于 MD5 应用的疑虑。不过，至今为止，MD5 冲突攻击没有被视为对摘要认证的威胁，并且

RFC 2617 允许服务器实现一些机制来检测冲突以及重放攻击。

HTTP摘要认证的考虑

优势

HTTP摘要认证目的在于比传统摘要认证构架更安全；例如，“明显强于（如）CRAM-MD5……”。 （RFC
2617）

一些HTTP摘要认证的安全性增强如下：

密码并非直接在摘要中使用，而是 HA1 = MD5(username:realm:password)。这就允许一些实现（如，JBoss

DIGESTAuth)仅存储 HA1 而不是明文密码。
在
RFC 2617 中引入了客户端随机数 nonce，这将使客户端能够防止选择明文攻击（否则，像Rainbow
table这类东西就会成为摘要认证构架的威胁）。
服务器随机数 nonce 允许包含时间戳。因此服务器可以检查客户端提交的随机数 nonce，以防止重放攻击。
服务器也可以维护一个最近发出或使用过的服务器随机数nonce的列表以防止重用。

劣势

摘要访问认证有意成为一个安全性的折衷。它意图代替非加密的HTTP基本认证。但是，它没有被设计为替换强认证协议，例如公钥密码学或Kerberos认证。

在安全性方面，摘要访问认证有几个缺点：

RFC 2617 中的许多安全选项都是可选的。如果服务器没有指定保护质量(qop)，客户端将以降低安全性的早期的

RFC 2069 的模式操作。
摘要访问认证容易受到中间人攻击。举例而言，一个中间人攻击者可以告知客户端使用基本访问认证或早期的RFC
2069摘要访问认证模式。进一步而言，摘要访问认证没有提供任何机制帮助客户端验证服务器的身份。
一些服务器要求密码以可逆加密算法存储。但是，仅存储用户名、realm、和密码的摘要是可能的。[2]
它阻止了使用强密码哈希函数（如bcrypt）保存密码（因为无论是密码、或者用户名、realm、密码的摘要都要求是可恢复的）。

可替代的认证协议

一些可以用于Web应用程序的强认证协议包括：

公钥密码学认证（通常随
HTTPS /

SSL客户端整数一起实现）。
Kerberos或SPNEGO认证，主要是在配置为Integrated
Windows Authentication (IWA)的微软的IIS使用。
Secure Remote Password protocol (适用于HTTPS
/
TLS层)。

常用的弱明文协议：

HTTP基本认证构架
HTTP+HTML表单认证

使用HTTPS网络加密同时使用这些弱明文协议解决了许多摘要访问认证试图要防止的许多威胁。

示例及说明

下面的例子出自
RFC 2617，在这里进行了扩展，对每一个请求和响应显示出完整的文本。注意，这里仅仅涵盖了“auth”保护质量的代码，因为在撰写期间，所知道的只有Opera和Konqueror网页浏览器支持“auth-int”（带完整性保护的认证）。虽然定义中提到了HTTP
1.1，但是该构架可以像下面所描述的这样添加到1.0的服务器中去。

典型的认证过程包括如下步骤。

客户端请求一个需要认证的页面，但是不提供用户名和密码。通常这是由于用户简单的输入了一个地址或者在页面中点击了某个超链接。
服务器返回401 "Unauthorized" 响应代码，并提供认证域(realm)，以及一个随机生成的、只使用一次的数值，称为密码随机数
nonce。
此时，浏览器会向用户提示认证域(realm)（通常是所访问的计算机或系统的描述），并且提示用户名和密码。用户此时可以选择取消。
一旦提供了用户名和密码，客户端会重新发送同样的请求，但是添加了一个认证头包括了响应代码。
在这个例子中，服务器接受了认证并且返回了请求页面。如果用户名非法和/或密码不正确，服务器将返回"401"响应代码，然后客户端会再次提示用户输入用户名及密码。

注意：客户端可能已经拥有了用户名和密码，因此不需要提示用户，比如以前存储在浏览器里的。

客户端请求 (无认证)

GET /dir/index.html HTTP/1.0
Host: localhost

(跟随一个新行，形式为一个回车再跟一个换行）
[3]

服务器响应

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>

客户端请求 (用户名 "Mufasa", 密码 "Circle Of Life")

GET /dir/index.html HTTP/1.0
Host: localhostAuthorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

(跟随一个新行，形式如前所述).

服务器响应

HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

(随后是一个空行，然后是所请求受限制的HTML页面).

如下所述，response 值由三步计算而成。当多个数值合并的时候，使用冒号作为分割符。

对用户名、认证域(realm)以及密码的合并值计算 MD5 哈希值，结果称为 HA1。
对HTTP方法以及URI的摘要的合并值计算 MD5 哈希值，例如，

"GET"

和

"/dir/index.html"

，结果称为 HA2。
对 HA1、服务器密码随机数(nonce)、请求计数(nc)、客户端密码随机数(cnonce)、保护质量(qop)以及 HA2 的合并值计算 MD5 哈希值。结果即为客户端提供的 response 值。

因为服务器拥有与客户端同样的信息，因此服务器可以进行同样的计算，以验证客户端提交的 response 值的正确性。在上面给出的例子中，结果是如下计算的。 （

MD5()

表示用于计算 MD5 哈希值的函数；“\”表示接下一行；引号并不参与计算）

完成
RFC 2617 中所给出的示例，将在每步得出如下结果。

HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9

HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366

Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1

此时客户端可以提交一个新的请求，重复使用服务器密码随机数(nonce)（服务器仅在每次“401”响应后发行新的nonce），但是提供新的客户端密码随机数(cnonce)。在后续的请求中，十六进制请求计数器(nc)必须比前一次使用的时候要大，否则攻击者可以简单的使用同样的认证信息重放老的请求。由服务器来确保在每个发出的密码随机数nonce时，计数器是在增加的，并拒绝掉任何错误的请求。显然，改变HTTP方法和/或计数器数值都会导致不同的
response 值。

服务器应当记住最近所生成的服务器密码随机数nonce的值。也可以在发行每一个密码随机数nonce后，记住过一段时间让它们过期。如果客户端使用了一个过期的值，服务器应该响应“401”状态号，并且在认证头中添加

stale=TRUE

，表明客户端应当使用新提供的服务器密码随机数nonce重发请求，而不必提示用户其它用户名和口令。

服务器不需要保存任何过期的密码随机数，它可以简单的认为所有不认识的数值都是过期的。服务器也可以只允许每一个服务器密码随机数nonce使用一次，当然，这样就会迫使客户端在发送每个请求的时候重复认证过程。需要注意的是，在生成后立刻过期服务器密码随机数nonce是不行的，因为客户端将没有任何机会来使用这个nonce。