前端学HTTP之摘要认证

前面的话

　　上一篇介绍的基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式传送的，也没有采起任何措施防止对报文的篡改。安全使用基本认证的惟一方式就是将其与SSL配合使用

　　摘要认证与基本认证兼容，但却更为安全。本文将详细介绍绍摘要认证的原理和实际应用

 

工做原理

　　摘要认证是另外一种HTTP认证协议，它试图修复基本认证协议的严重缺陷。具体来讲，摘要认证进行了以下改进：永远不会以明文方式在网络上发送密码；能够防止恶意用户捕获并重放认证的握手过程；能够有选择地防止对报文内容的篡改；防范其余几种常见的攻击方式

　　摘要认证并非最安全的协议，并不能知足安全HTTP事务的不少需求。对这些需求来讲，使用传输层安全(Transport Layer Security, TLS)和安全HTTP(Secure HTTP, HTTPS)协议更为合适一些

　　但摘要认证比它要取代的基本认证强大不少。与不少建议其余因特网服务使用的经常使用策略相比，(好比曾建议LDAP、POP和IMAP使用的CRAM-MD5)，摘要认证也要强大不少

　　迄今为止，摘要认证尚未被普遍应用。但因为基本认证存在固有的安全风险，HTTP设计者曾在RFC 2617中建议：“在可行的状况下应该将目前在用的全部使用基本认证的服务，尽快地转换为摘要认证方式”

　　摘要认证遵循的箴言是“毫不经过网络发送密码”。客户端不会发送密码，而是会发送一个“指纹”或密码的“摘要”，这是密码的不可逆扰码。客户端和服务器都知道这个密码，所以服务器能够验证所提供的摘要是否与密码相匹配。只拿到摘要的话，除了将全部的密码都拿来试试以外，没有其余方法能够找出摘要是来自哪一个密码

　　经过下图能够了解摘要认证的工做原理

　　在图a中，客户端请求了某个受保护文档

　　在图b中，在客户端可以证实其知道密码从而确认其身份以前，服务器拒绝提供文档。服务器向客户端发起质询，询问用户名和摘要形式的密码

　　在图c中，客户端传递了密码的摘要，证实它是知道密码的。服务器知道全部用户的密码，所以能够将客户提供的摘要与服务器本身计算获得的摘要进行比较，以验证用户是否知道密码。另外一方在不知道密码的状况下，很难伪造出正确的摘要

　　在图d中，服务器将客户端提供的摘要与服务器内部计算出的摘要进行对比。若是匹配，就说明客户端知道密码。能够设置摘要函数，使其产生不少数字，让人不可能幸运地猜中摘要。服务器进行了匹配验证以后，会将文档提供给客户端——整个过程都没有在网络上发送密码

【单向摘要】

　　摘要是“对信息主体的浓缩”，它是一种单向函数，主要用于将无限的输入值转换为有限的浓缩输出值。常见的摘要函数MD5，会将任意长度的字节序列转换为一个128位的摘要

　　对这些摘要来讲，最重要的是若是不知道密码的话，要想正确地猜出发送给服务器的摘要将是很是困难的。一样，若是有摘要，想要判断出它是由无数输入值中的哪个产生的，也是很是困难的

　　MD5输出的128位的摘要一般会被写成32个十六进制的字符，每一个字符表示4位。下表中给出了几个示例输入的MD5摘要

　　有时也将摘要函数称为加密的校验和、单向散列函数或指纹函数

【用随机数防止重放攻击】

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

　　可是，仅仅隐藏密码并不能避免危险，由于即使不知道密码，别有用心的人也能够截获摘要，并一遍遍地重放给服务器。摘要和密码同样好用

　　为防止此类重放攻击的发生，服务器能够向客户端发送一个称为随机数(nonce)的特殊令牌，这个数会常常发生变化(多是每毫秒，或者是每次认证都变化)。客户端在计算摘要以前要先将这个随机数令牌附加到密码上去

　　在密码中加入随机数就会使摘要随着随机数的每一次变化而变化。记录下的密码摘要只对特定的随机值有效，而没有密码的话，攻击者就没法计算出正确的摘要，这样就能够防止重放攻击的发生

　　摘要认证要求使用随机数，由于这个小小的重放弱点会使未随机化的摘要认证变得和基本认证同样脆弱。随机数是在WWW-Authenticate质询中从服务器传送给客户端的

【握手机制】

　　HTTP摘要认证协议是一种升级版的认证方式，所用首部与基本认证相似。它在传统首部中添加一些新的选项，还添加了一个新的可选首部Authorization-Info

　　下图描述了简化的摘要认证三步握手机制

　　在第(1)步中，服务器会计算出一个随机数

　　在第(2)步中，服务器将这个随机数放在WWW-Authenticate质询报文中，与服务器所支持的算法列表一同发往客户端

　　在第(3)步中，客户端选择一个算法，计算出密码和其余数据的摘要

　　在第(4)步中，将摘要放在一条Authorization报文中发回服务器。若是客户端要对服务器进行认证，能够发送客户端随机数

　　在第(5)步中，服务器接收摘要、选中的算法以及支撑数据，计算出与客户端相同的摘要。而后服务器将本地生成的摘要与网络传送过来的摘要进行比较，验证其是否匹配。若是客户端反过来用客户端随机数对服务器进行质询，就会建立客户端摘要。服务器能够预先将下一个随机数计算出来，提早将其传递给客户端，这样下一次客户端就能够预先发送正确的摘要了

　　这些信息中不少是可选的，并且有默认值

　　下图中对比了基本认证和摘要认证的工做原理

摘要算法

　　摘要认证的核心就是对公共信息、保密信息和有时限的随机值这个组合的单向摘要

　　摘要是根据由单向散列函数H(rf)和摘要KD(s,d)组成的一对函数，其中s表示密码，d表示数据；和一个包含了安全信息的数据块，包括密码，称为A1；以及一个包含了请求报文中非保密属性的数据块，称为A2这三个组件计算出来的。H和KD处理两块数据A1和A2，产生摘要

　　摘要认证支持对各类摘要算法的选择。RFC 2617建议的两种算法为MD5和MD5-sess(“sess”表示会话)，若是没有指定其余算法，默认算法为MD5

　　无论使用的是MD5仍是MD5-sess，都会用函数H来计算数据的MD5，用摘要函数KD来计算以冒号链接的密码和非保密数据的MD5

H(<data>) = MD5(<data>)
KD(<secret>,<data>) = H(concatenate(<secret>:<data>))

　　被称为A1的数据块是密码和受保护信息的产物，它包含有用户名、密码、保护域和随机数等内容。A1只涉及安全信息，与底层报文自身无关。A1会与H、KD和A2一同用于摘要计算

　　RFC 2617根据选择的算法定义了两种计算A1的方式

　　一、MD5

　　为每条请求运行单向散列函数。A1是由冒号链接起来的用户名、域以及密码三元组

　　二、MD5-sess

　　只在第一次WWW-Authenticate握手时运行一次散列函数。对用户名、域和密码进行一次CPU密集型散列，并将其放在当前随机数和客户端随机数(cnonce)的前面

　　数据块A2表示的是与报文自身有关的信息，好比URL、请求方法和报文实体的主体部分。A2有助于防止方法、资源或报文被篡改。A2会与H、KD和A1一块儿用于摘要的计算

　　RFC 2617根据所选择的保护质量(qop)，为A2定义了两种策略

　　第一种策略只包含HTTP请求方法和URL。当qop="auth"时使用这种策略，这是默认的状况

　　第二种策略添加了报文实体的主体部分，以提供必定程度的报文完整性检测。qop="auth-int"时使用

　　request-method是HTTP的请求方法。uri-directive-value是请求行中的请求URI。多是个"*"、absoluteURL或者abs_path，但它必须与请求URI一致。若是请求URI是absoluteURL，它必须是个绝对URL

　　RFC 2617定义了两种给定了H、KD、A1和A2以后，计算摘要的方式

　　第一种方式要与老规范RFC 2069兼容，在没有qop选项的时候使用。它是用保密信息和随机报文数据的散列值来计算摘要的

　　第二种方式是如今推荐使用的方式——这种方式包含了对随机数计算和对称认证的支持。只要qop为auth或auth-int，就要使用这种方式。它向摘要中添加了随机计数、qop和cnonce数据

　　客户端响应对保护空间的WWW-Authenticate质询时，会启动一个此保护空间的认证会话(与受访问服务器的标准根结合在一块儿的域就定义了一个“保护空间”)

　　在客户端收到另外一条来自保护空间的任意一台服务器的WWW-Authenticate质询以前，认证会话会一直持续。客户端应该记住用户名、密码、随机数、随机数计数以及一些与认证会话有关的隐晦值，以便未来在此保护空间中构建请求的 Authorization首部时使用

　　随机数过时时，即使老的Authorization首部所包含的随机数再也不新鲜了，服务器也能够选择接受其中的信息。服务器也能够返回一个带有新随机数的401响应，让客户端重试这条请求，指定这个响应为Stale=true，表示服务器在告知客户端用新的随机数来重试，而再也不从新提示输入新的用户名和密码了

【预受权】

　　在普通的认证方式中，事务结束以前，每条请求都要有一次请求/质询的循环，如图a

　　若是客户端事先知道下一个随机数是什么，就能够取消这个请求/质询循环，这样客户端就能够在服务器发出请求以前，生成正确的Authorization首部了。若是客户端能在服务器要求它计算Authorization首部以前将其计算出来，就能够预先将Authorization首部发送给服务器，而不用进行请求/质询了。图b显示了这种方式对性能的影响
 
　　预受权对基本认证来讲并不重要，并且很常见。浏览器一般会维护一些客户端数据库以存储用户名和密码。一且用户与某站点进行了认证，浏览器一般会为后继对那个URL的请求发送正确的Authorization首部

　　因为摘要认证使用了随机数技术来破坏重放攻击，因此对摘要认证来讲，预受权要稍微复杂一些。服务器会产生任意的随机数，因此在客户端收到质询以前，不必定总能断定应该发送什么样的Authorization首部

　　摘要认证在保留了不少安全特性的同时，还提供了几种预受权方式。这里列出了三种可选的方式，经过这些方式，客户端无需等待新的WWW-Authenticate质询，就能够得到正确的随机数

　　一、服务器预先在Authentication-Info成功首部中发送下一个随机数

　　能够在Authentication-Info成功首部中将下一个随机数预先提供给客户端。这个首部是与前一次成功认证的200 OK响应一同发送的

　　Authentication-Info: nextnonce="<nonce-value>"

　　有了下一个随机数，客户端就能够预先发布Authorization首部了

　　尽管这种预受权机制避免了请求/质询循环，加快了事务处理的速度，但实际上它也破坏了对同一台服务器的多条请求进行管道化的功能，由于在发布下一条请求以前，必定要收到下一个随机值才行。而管道化是避免延迟的一项基本技术，因此这样可能会形成很大的性能损失

　　二、服务器容许在一小段时间内使用同一个随机数

　　第二种方法是在有限的次数内重用随机数。好比，服务器可能容许将某个随机数重用5次，或者重用10秒

　　在这种状况下，客户端能够随意发布带有Authorization首部的请求，并且因为随机数是事先知道的，因此还能够对请求进行管道化。随机数过时时，服务器要向客户端发送 401 Unauthorized 质询，并设置WWW-Authenticate:stale=true指令

WWW-Authenticate:Digest realm="<realm-value>" nonce="<nonce-value>" stale=true

　　重用随机数使得攻击者更容易成功地实行重放攻击。虽然这确实下降了安全性，但重用的随机数的生存期是可控的，从严格禁止重用到较长时间的重用，因此应该能够在安全和性能间找到平衡

　　此外，还能够经过其余一些特性使重放攻击变得更加闲难，其中就包括增置计数器和IP地址测试。但这些技术只能使攻击的实施更加麻烦，并不能消除由此带来的安全隐患

　　三、客户端和服务器使用同步的、可预测的随机数生成算法

　　第三种方法是采用时间同步的随机数生成算法，客户端和服务器可根据共享的密钥，生成第三方没法轻易预测的、相同的随机数序列(好比安全ID卡)

【随机数】

　　随机数的内容不透明，并且与实现有关。但性能、安全性和便捷性的优劣都取决于明智的选择

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

BASE64(time-stamp H(time-stamp "" ETag ":" private-key))

　　其中time-stamp是服务器产生的时间或其余不会重复的值，ETag是与所请求实体有关的HTTP ETag首部的值，private-key是只有服务器知道的数据

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

　　包含Etag能够防止对已更新资源版本的重放请求。在随机数中包含客户端的IP地址，服务器好像就能够限制原来得到此随机数的客户端重用这个随机数了，但这会破坏代理集群的工做。使用代理集群时，来自单个用户的多条请求一般会通过不一样的代理进行传输，并且IP地址欺骗实现起来也不是很难

　　实现能够选择不接受之前使用过的随机数或摘要，以防止重放攻击。实现也能够选择为POST或PUT请求使用一次性的随机数或摘要，为GET请求使用时间戳

【对称认证】

　　RFC 2617扩展了摘要认证机制，容许客户端对服务器进行认证。这是经过提供客户端随机值来实现的，服务器会根据它对共享保密信息的正确了解生成正确的响应摘要。而后，服务器在Authorization-Info首部中将此摘要返回给客户端

　　这种对称认证方式被标准化为RFC 2617。为了与原有RFC 2069标准后向兼容，它是可选的，但因为它提供了一些重要的安全提高机制，强烈推荐现今全部的客户端和服务器都要实现所有RFC 2617特性。特别是，只要提供了qop指令，就要求执行对称认证，而没有qop指令时则不要求执行对称认证

　　响应摘要的计算方法与请求摘要相似，但因为响应中没有方法，并且报文实体数据有所不一样，因此只有报文主体信息A2不一样
　　下表是请求摘要中A2的定义

　　下表是响应摘要中A2的定义

　　cnonce值和nc值必须是本报文所响应的客户端请求中的相应值。若是指定了gop="auth"或qop="auth-int"，就必须提供响应auth、cnonce和nonce计数指令

 

加强保护

　　能够在三种摘要首部中提供qop字段：WWW-Authenticate、Authorization和Authentication-Info

　　经过qop字段，客户端和服务器能够对不一样类型及质询的保护进行协商。好比，即使会严重下降传输速度，有些事务可能也要检査报文主体的完整性

　　服务器首先在WWW-Authenticate首部输出由逗号分隔的qop选项列表。而后客户端从中选择一个它支持且知足其需求的选项，并将其放在Authorization的qop字段中回送给服务器

　　qop字段是可选的，但只是在后向兼容原有RFC 2069规范的状况下才是可选的。现代全部的摘要实现都应该支持qop选项

RFC 2617定义了两种保护质量的初始值：表示认证的auth，带有报文完整性保护的认证auth-int。未来可能还会出现其余qop选项

　　若是使用了完整性保护(qop="auth-int")，H(实体的主体部分)就是对实体主体部分，而不是报文主体部分的散列。对于发送者，要在应用任意传输编码方式以前计算；而对于接收者，则应在去除全部传输编码以后计算。注意，对于任何含有多部份的内容类型来讲，多部分的边界和每部分中嵌入的首部都要包含在内

　　基本认证和摘要认证协议都包含了WWW-Authenticate首部承载的受权质询、Authorization首部承载的受权响应。摘要认证还添加了可选的Authorization-info首部，这个首部是在成功认证以后发送的，用于实现三步握手机制，并传送下一个随机数。下表给出了基本认证和摘要认证的首部

实际问题

　　使用摘要认证时须要考虑如下几个实际问题

【多重质询】

　　服务器能够对某个资源发起多重质询。好比，若是服务器不了解客户端的能力，就能够既提供基本认证质询，又提供摘要认证质询。客户端面对多重质询时，必须以它所支持的最强的质询机制来应答

　　质询自身可能会包含由逗号分隔的认证参数列表。若是WWW-Authenticate或Proxy-Authenticate首部包含了多个质询，或者提供了多个WWW-Authenticate首部，用户Agent代理在解析WWW-Authenticate或Proxy-Authenticate首部字段值时就要特别当心

　　[注意]不少浏览器只支持基本认证，要求这是提交给它的第一种认证机制

　　在提供了认证选项范围的状况下，安全问题上就会存在明显的“最薄弱环节”。只有当基本认证是最低可接受认证方式时，服务器才应该包含它，并且管理员还应该警告用户，即便运行了不一样层次安全措施，系统间使用相同密码也存在必定危险性

【差错处理】

　　在摘要认证中，若是某个指令或其值使用不当，或者缺乏某个必要指令，就应该使用响应400 Bad Request

　　若是请求的摘要不匹配，就应该记录一次登陆失败。某客户端连续屡次失败可能说明有攻击者正在猜想密码

　　认证服务器必定要确保URI指令指定的资源与请求行中指定的资源相同。若是不一样，服务器就应该返回400 Bad Request错误。这多是一种攻击的迹象，所以服务器设计者可能会考虑将此类错误记录下来。这个字段包含的内容与请求URL中的内容是重复的，用来应对中间代理可能对客户端请求进行的修改。这个通过修改(但估计语义是等价的)的请求计算后获得的摘要可能会与客户端计算出的摘要有所不一样

【保护空间】

　　域值，与被访问服务器的标准根URL结合在一块儿，定义了保护空间

　　经过域能够将服务器上的受保护资源划分为一组保护空间，每一个空间都有本身的认证机制和(或)受权数据库。域值是一个字符串，一般由原始服务器分配，可能会有认证方案特有的附加语义

　　[注意]可能会有多个受权方案相同，而域不一样的质询

　　保护空间肯定能够自动应用证书的区域。若是前面的某条请求已被受权，在一段时间内，该保护空间中全部其余请求均可以重用同一个证书，时间的长短由认证方案、参数和(或)用户喜爱来决定。除非认证方案进行了其余定义，不然单个保护空间是不能扩展到其服务器范围以外的

　　对保护空间的具体计算取决于认证机制

　　在基本认证中，客户端会假定请求URI中或其下的全部路径都与当前的质询处于同一个保护空间内。客户端能够预先提交对此空间中资源的认证，无需等待来自服务器的另外一条质询

　　在摘要认证中，质询的WWW-Authenticate:domain字段对保护空间做了更精确的定义。domain字段是一个用引号括起来的、中间由空格分隔的URI列表。一般认为，domain列表中的全部URI和逻辑上处于这些前缀之下的全部URI，都位于同一个保护空间中。若是没有domain字段，或者此字段为空，质询服务器上的全部URI就都在保护空间内

【重写 URI】

　　代理能够经过改变URI语法，而不改变所描述的实际资源的方式来重写URI

　　能够对主机名进行标准化，或用IP地址来取代

　　能够用“%”转义形式来取代嵌入的字符

　　若是某类型的一些附加属性不会影响从特定原始服务器上获取资源，就能够将其附加或插入到URI中

　　代理可修改URI，并且摘要认证会检査URI值的完整性，因此若是进行了任意一种修改，摘要认证就会被破坏

【缓存】

　　共享的缓存收到包含Authorization首部的请求和转接那条请求产生的响应时，除非响应中提供了下列两种Cache-Control指令之一，不然必定不能将那条响应做为对任何其余请求的应答使用

　　一、若是原始响应中包含有Cache-Control指令must-revalidate，缓存能够在应答后继请求时使用那条响应的实体部分。但它首先要用新请求的请求首部，与原始服务器再次进行验证，这样原始服务器才能够对新请求进行认证

　　二、若是原始响应中包含有Cache-Control指令public，在对任意后继请求的应答中均可以返回响应的实体部分

 

安全考虑

【首部篡改】

　　为了提供一个简单明了的防首部篡改系统，要么就得进行端到端的加密，要么就得对首部进行数字签名——最好是二者的结合。摘要认证的重点在于提供一种防篡改认证机制，但并不必定要将这种保护扩展到数据上去。具备必定保护级别的首部只有WWW-Authenticate和Authorization

【重放攻击】

　　在当前的上下文中，重放攻击指的就是有人将从某个事务中窃取的认证证书用于另外一个事务。尽管对GET请求来讲这也是个问题，但为POST和PUT请求提供一种简单的方式来避免重放攻击才是很是必要的。在传输表单数据的同时，成功重放原先用过的证书会引起严重的安全问题

　　所以，为了使服务器可以接受“重放的”证书，还必须重复发送随机数。缓解这个问题的方法之一就是让服务器产生的随机数包含根据客户端IP地址、时间戳，资源Etag和私有服务器密钥算出的摘要。这样，IP地址和一个短小超时值的组合就会给攻击者形成很大的障碍

　　但这种解决方案有一个很重要的缺陷。用客户端IP地址来建立随机数会破坏通过代理集群的传输。在这类传输中，来自单个用户的多条请求可能会穿过不一样的代理。并且，IP欺骗也并不难实现

　　一种能够彻底避免重放攻击的方法就是为每一个事务都使用一个惟一的随机数。在这种实现方式中，服务器会为每一个事务发布惟一的随机数和一个超时值。发布的随机数只对指定的事务有效，并且只在超时值的持续区间内有效。这种方式会增长服务器的负担，但这种负担可忽略不计

【多重认证机制】

　　服务器支持多重认证机制(好比基本认证和摘要认证)时，一般会在WWW-Authenticate首部提供选项。因为没有要求客户端选择功能最强的认证机制，因此获得的认证效果就和功能最弱的认证方案差很少

　　要避免出现这个问题，最直接的方法就是让客户端老是去选择可用认证方案中功能最强的那个。若是没法实现，惟一的选择就是使用一个只维护最强认证方案的代理服务器，但只有在已知全部客户端都支持所选认证方案的区域中才能采用这种方式

【词典攻击】

　　词典攻击是典型的密码猜想型攻击方式。恶意用户对某个事务进行窃听，并对随机数/响应对使用标准的密码猜想程序。若是用户使用的是相对比较简单的密码，并且服务器使用的也是简单的随机数，它极可能会找到匹配项。若是没有密码过时策略，只要有足够的时间和破解密码所需的一次性费用，就很容易搜集到足够多的密码，形成实质性的破坏

　　除了使用复杂的相对难以破译的密码和合适的密码过时策略以外，确实没有什么好的方法能够解决这个问题

【恶意代理攻击和中间人攻击】

　　如今不少因特网流量都会在这个或那个地方流经某个代理。随着重定向技术和拦截代理的出现，用户甚至都意识不到他的请求穿过了某个代理。若是这些代理中有一个是恶意的或者容易被入侵的，就会使客户端置于中间人攻击之下

　　这种攻击能够采用窃听的形式，也能够删除提供的全部选项，用最薄弱的认证策略(好比基本认证)来取代现有的认证机制，对其进行修改

　　入侵受信代理的方式之一就是使用其扩展接口。有时代理会提供复杂的编程接口，能够为这类代理编写一个扩展(好比，plug-in)来拦截流量并对其进行修改。不过，数据中心和代理自身提供的安全性使得经过恶意plug-in进行中间人攻击的可能性变得很渺茫

　　没有什么好办法能够解决这个问题。可行的解决方案包括由客户端提供与认证功能有关的可见线索，对客户端进行配置使其老是使用可用认证策略中功能最强的那一种等等。但即便使用的是最强大的认证策略，客户端仍然很容易被窃听。防止这些攻击惟一简便的方式就是使用SSL

【选择明文攻击】

　　使用摘要认证的客户端会用服务器提供的随机数来生成响应。但若是中间有一个被入侵的或恶意的代理在拦截流量(或者有个恶意的原始服务器)，就能够很容易地为客户端的响应计算提供随机数。使用已知密钥来计算响应能够简化响应的密码分析过程。这种方式被称为选择明文攻击(chosen plaintext attack)。选择明文攻击有如下几种变体形式

　　一、预先计算的词典攻击

　　这是词典攻击和选择明文攻击的组合。首先，发起攻击的服务器会用预先肯定的随机数和常见密码的变化形式产生一组响应，建立一个词典。一旦有了规模可观的词典，攻击服务器或代理就能够完成对流量的封锁，向客户端发送预先肯定的随机数。攻击者从客户端获得一个响应时，会搜索生成的词典，寻找匹配项。若是有匹配项，攻击者就捕获了这个用户的密码

　　二、批量暴力型攻击

　　批量暴力型攻击的不一样之处在于计算密码的方式。它没有试图去匹配预先计算出来的摘要，而是用一组机器枚举了指定空间内全部可能的密码。随着机器运行速度变得愈来愈快，暴力型攻击的可行性也变得愈来愈强了

　　总之，这些攻击所形成的威胁是很容易应对的。防止这些攻击的一种方法就是配置客户端使用可选的cnonce指令，这样响应就是基于客户端的判断产生的，而不是用服务器提供的随机数(这个随机数可能会被攻击者入侵)产生的。经过这种方法，再结合一些强制使用合理强密码的策略，以及一个好的密码过时策略，就能够彻底消除选择明文攻击的威胁

【存储密码】

　　摘要认证机制将对比用户的响应与服务器内部存储的内容——一般就是用户名和H(A1)元组对，其中H(A1)是从用户名、域和密码的摘要中导出的

　　与Unix机器中传统的密码文件不一样，若是摘要认证密码文件被入侵了，攻击者立刻就可以使用域中全部文件，不须要再进行解码了

　　消除这个问题的方法包括：就像密码文件中包含的是明文密码同样来保护它；确保域名在全部域中是惟一的。这样，若是密码文件被入侵，所形成的破坏也只局限于一个特定的域中。包含主机和domain的全路径域名就能够知足这个要求

　　尽管摘要认证提供的解决方案比基本认证要强壮且安全得多，但它并无为内容的安全提供任何保证——真正安全的事务只有经过SSL才能实现

 

指令描述

　　下表中根据RFC 2617描述，对WWW-Authenticate指令进行了详细说明

　　下表对Authentication指令进行了详细说明

　　下表对Authentication-Info指令进行了详细说明