详解HTTP中的摘要认证机制

基本认证方式是存在很多缺陷的，具体表现如下：

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服务器质询响应中从服务器传输给客户端的。

 

三，摘要认证的握手过程

1，  第一次客户端请求的时候，服务器产生一个随机数nonce，服务器将这个随机数放在WWW-Authenticate响应头，与服务器支持的认证算法列表，认证的域realm一起发送给客户端，如下例子：

HTTP /1.1 401 Unauthorized

WWW-Authenticate:Digest

realm= ”test realm”

qop=auth,auth-int”

nonce=”66C4EF58DA7CB956BD04233FBB64E0A4”

这里包括了一组参数，也要发送给用户。用户使用这些参数，来产生正确的摘要回答，并发送给服务器。摘要盘问中的各个参数，其意义如下：

    realm（领域）：领域参数是强制的，在所有的盘问中都必须有。它是目的是鉴别SIP消息中的机密。在SIP实际应用中，它通常设置为SIP代理服务器所负责的域名。

    在要求用户输入用户名和口令时，SIP用户代理则会显示这个参数的内容给用户，以便用户使用正确的用户名和口令（这个服务器的）。

    nonce （现时）：这是由服务器规定的数据字符串，在服务器每次产生一个摘要盘问时，这个参数都是不一样的（与前面所产生的不会雷同）。“现时”通常是由一些数据通过md5杂凑运算构造的。这样的数据通常包括时间标识和服务器的机密短语。这确保每个“现时”都有一个有限的生命期（也就是过了一些时间后会失效，并且以后再也不会使用），而且是独一无二的（即任何其它的服务器都不能产生一个相同的“现时”）。

    客户端使用这个“现时”来产生摘要响应（digest response），这样服务器也会在一个摘要响应中收到“现时”的内容。服务器先要检查了“现时”的有效性后，才会检查摘要响应的其它部分。

    因而，“现时”在本质上是一种标识符，确保收到的摘要机密，是从某个特定的摘要盘问产生的。还限制了摘要盘问的生命期，防止未来的重播攻击。

    opaque（不透明体）：这是一个不透明的（不让外人知道其意义）数据字符串，在盘问中发送给用户。

    在摘要响应中，用户会将这个数据字符串发送回给服务器。这使得服务器可以是无状态的。如果需要在盘问和响应之间维护一些状态，可以用这个参数传送状态给客户端，此后当摘要响应回来时，再读这个状态。

    algorithm（算法）：这是用来计算杂凑的算法。当前只支持MD5算法。

    qop（保护的质量）。这个参数规定服务器支持哪种保护方案。客户端可以从列表中选择一个。值

    “auth”表示只进行身份查验， “auth-int”表示进行查验外，还有一些完整性保护

 

2，  客户端发现是401响应，表示需要进行认证，则弹出让用户输入用户名和密码的认证窗口，客户端选择一个算法，计算出密码和其他数据的摘要，将摘要放到Authorization的请求头中发送给服务器，如果客户端要对服务器也进行认证，这个时候，可以发送客户端随机数cnonce。如下例子：

GET/cgi-bin/checkout?a=b HTTP/1.1

Authorization: Digest

username=”tenfyguo”

          realm=”test realm”

          nonce=” 66C4EF58DA7CB956BD04233FBB64E0A4” //服务器端的随机数一起带回

          uri=”/cgi-bin/checkout?a=b” //必须跟请求行一致

          qop=”auth” //保护质量参数

          nc=0000001

          cnonce=”xxxxx234132543strwerr65sgdrftdfytryts” //客户端随机数，用于对称校验

          response=” ABC4EF58DA7CB956BD04345FBB64E0A4”//最终摘要

  摘要响应类似于摘要盘问。相同的参数，则与摘要盘问有相同的意义。这里只描述新的参数：

    uri（统一资源指示符）：这个参数包含了客户端想要访问的URI。 
    qop：客户端选择的保护方式。 
    nc：“现时”计数器，这是一个16进制的数值，即客户端发送出请求的数量（包括当前这个请求），这些请求都使用了当前请求中这个“现时”值。例如，对一个给定的“现时”值，在响应的第一个请求中，客户端将发送“nc=00000001”。这个指示值的目的，是让服务器保持这个计数器的一个副本，以便检测重复的请求。如果这个相同的值看到了两次，则这个请求是重复的。

    cnonce：这也是一个不透明的字符串值，由客户端提供，并且客户端和服务器都会使用，以避免用明文文本。这使得双方都可以查验对方的身份，并对消息的完整性提供一些保护。

    response（响应）：这是由用户代理软件计算出的一个字符串，以证明用户知道口令。

3，  服务接受摘要，选择算法以及掌握的数据，重新计算新的摘要跟客户端传输的摘要进行比较，验证是否匹配，若客户端反过来用客户端随机数对服务器进行质询，就会创建客户端摘要，服务可以预先将下一个随机数计算出来，提前传递给客户端，通过Authentication-Info发送下一个随机数。如下例子：

HTTP/1.1 200 OK

Authorization-Info:nextnonce=” 88C4EF58DA7CB956BD04233FBB64E0A4”

qop=”auth”

rspauth=”23543534DfasetwerwgDTerGDTERERRE”

cnonce=” xxxxx234132543strwerr65sgdrftdfytryts”

 

 

四，摘要的计算

在说明如何计算摘要之前，先说明参加摘要计算的信息块。信息块主要有两种：

1，表示与安全相关的数据的A1。

A1中的数据时密码和受保护信息的产物，它包括用户名，密码，保护域和随机数等内容，A1只涉及安全信息，与底层报文自身无关。

若算法是：MD5

则A1=<user>:<realm>:<password>

若算法是：MD5-sess

则A1=MD5(<user>:<realm>:<password>):<nonce>:<cnonce>

 

2，表示与报文相关的数据的A2.

A2表示是与报文自身相关的信息，比如URL，请求反复和报文实体的主体部分，A2加入摘要计算主要目的是有助于防止反复，资源或者报文被篡改。

若qop未定义或者auth：

A2=<request-method>:<uri-directive-value>

若qop为auth:-int

A2=<request-method>:<uri-directive-value>:MD5(<request-entity-body>)

 

 

下面定义摘要的计算规则：

若qop没有定义：

摘要response=MD5(MD5(A1):<nonce>:MD5(A2))

 

若qop为auth:

摘要response=MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2))

 

若qop为auth-int:

摘要response= MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2))

 

五，随机数的生成

RFC2617建议采用这个假想的随机数公式：

 nonce = BASE64(time-stamp MD5(time-stamp  “:” ETag  “:”  private-key))

其中:

time-stamp是服务器产生的时间戳或者其他不会重复的序列号，ETag是与所请求实体有关的HTTP ETag首部的值，priviate-key是只有服务器知道的数据。

 

这样，服务器就可以收到客户端的认证首部之后重新计算散列部分，如果结果与那个首部的随机数不符，或者是时间戳的值不够新，就可以拒绝请求，服务器可以通过这种方式来限制随机数的有效持续时间。

 

包括了ETag可以防止对已经更新资源版本的重放请求。注意：在随机数中包含客户端IP，服务器好像就可以限制原来获取此随机数的客户端重用这个随机数了，但这会破坏代理集群的工作，使用代理集群时候，来自单个用户的多条请求通常会经过不同的代理进行传输，而且IP地址欺骗实现起来也不复杂。