sip 认证分析

转自：http://blog.csdn.net/wangqi0079/article/details/11569489

SIP类似Http协议。其认证模式也一样。Http协议（RFC 2616 ）规定可以采用Basic模式和摘要模式（Digest schema）。RFC 2617 专门对两种认证模式做了规定。RFC 1321 是MD5标准。Digest对现代密码破解来说并不强壮，但比基本模式还是好很多。

1、基本认证模式
客户向服务器发送请求，服务器返回401（未授权），要求认证。401消息的头里面带了challenge信息。realm用以区分要不同认证的部分。客户端收到401后，将用户名密码和challenge信息用BASE64加密形成证书，发送回服务器认证。语法如下：
       challenge   = "Basic" realm
      credentials = "Basic" basic-credentials
示例：
   认证头： WWW-Authenticate: Basic realm= "wang.guoliang2@zte.com.cn"
   证书：Authorization: Basic QsdfgWGHffuIcaNlc2FtZQ

2、摘要访问认证
在客户发送请求后，收到一个401（未授权）消息，包含一个Challenge。消息里面有一个唯一的字符串：nonce，每次请求都不一样。客户将用户名密码和401消息返回的Challenge一起加密后传给服务器。语法如下：
      challenge        = "Digest" digest-challenge
      digest-challenge = 1#( realm | [ domain ] | nonce | [opaque] |[stale] | [algorithm] | [qop-options] | [auth-param] )
      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
      URI               = absoluteURI | abs_path
      nonce             = "nonce" "=" nonce-value
      nonce-value       = quoted-string
      opaque            = "opaque" "=" quoted-string
      stale             = "stale" "=" ( "true" | "false" )
      algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
      qop-options       = "qop" "=" <"> 1#qop-value <">
      qop-value         = "auth" | "auth-int" | token
realm：让客户知道使用哪个用户名和密码的字符串。不同的领域可能密码不一样。至少告诉用户是什么主机做认证，他可能会提示用哪个用户名登录，类似一个Email。
domain：一个URI列表，指示要保护的域。可能是一个列表。提示用户这些URI采用一样的认证。如果为空或忽略则为整个服务器。
nonce：随机字符串，每次401都不一样。跟算法有关。算法类似Base64加密：time-stamp H(time-stamp ":" ETag ":" private-key) 。time-stamp为服务器时钟，ETag为请求的Etag头。private-key为服务器知道的一个值。
opaque：服务器产生的由客户下去请求时原样返回。最好是Base64串或十六进制字符串。
auth-param：为扩展用的，现阶段忽略。
其他域请参考RFC2617。授权头语法：
       credentials      = "Digest" digest-response
       digest-response = 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] |
                       [opaque] | [message-qop] | [nonce-count] | [auth-param] )
       username         = "username" "=" username-value
       username-value   = quoted-string
       digest-uri       = "uri" "=" digest-uri-value
       digest-uri-value = request-uri   ; As specified by HTTP/1.1
       message-qop      = "qop" "=" qop-value
       cnonce           = "cnonce" "=" cnonce-value
       cnonce-value     = nonce-value
       nonce-count      = "nc" "=" nc-value
       nc-value         = 8LHEX
       response         = "response" "=" request-digest
       request-digest = <"> 32LHEX <">
       LHEX             = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"
response：加密后的密码
digest-uri：拷贝Request-Line，用于Proxy
cnonce：如果qop设置，才设置，用于双向认证，防止攻击。
nonce-count:如果服务器看到同样的计数，就是一次重放。
示例：
401响应：        HTTP/1.1 401 Unauthorized
         WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
再次请求：
         Authorization: Digest username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

=================

http://www.cnblogs.com/my_life/articles/2285649.html

 

理解SIP的认证

 

1. 认证和加密

    认证（Authorization）的作用在于表明自己是谁，即向别人证明自己是谁。而相关的概念是MD5，用于认证安全。注意MD5仅仅是个hash函数而已，并不是用于加密。因为hash函数处理后的数据没法进行反向恢复，这样子的话别人没法盗取你认证身份的口令。

    加密（Encryption）的作用在于对想传输的数据进行处理，在网络中即使被窃取也难以破解。加密的信息可以被破解，这需要一把钥匙——“密钥”。通过密钥，我们可以对数据进行加密和解密。最有名的专用密钥加密系统就是数据加密标准(DES), 这个标准现在由美国国家安全局和国家标准与技术局来管理。另一个系统是国际数据加密算法(IDEA), 它比DES的加密性好, 而且需要的计算机功能也不怎么强。

2. SIP认证方式

    SIP的认证是继承了HTTP的认证方式。根据RFC2617，HTTP的认证方案主要有Basic Authentication Scheme和Digest Access Authentication Scheme两种。而Basic方法使用的口令原文验证的方式，易被盗取，所以SIP已经摒弃这种方式。

    Digest认证方案可以对口令进行MD5包装。一般来说，获取口令有两种方式：1.字典攻击，即使用轮询进行口令猜测的方法，如果口令简单比较危险；另一个方法是攻击服务器来获得口令，如果服务器把密码存储起来那样的话就可能被盗取。所以方法是服务器端不再存储密码原文，而是使用MD5包装起来，这样的话当经过MD5包装的认证信息过来后，比较存储的MD5数据则可知道用户的身份了。

3. SIP认证过程

UA之间的认证

图1-1 UA之间的认证流程

 

UA和Proxy之间的认证

图1-2 UA和Proxy之间的认证流程

 

     从以上两图看出，首先当UAC给UAS/Proxy发请求时；如果UAS/Proxy需要认证信息，则回复401/407；这时UAC通过回复信息来计算认证消息，然后重新发送 请求；如果认证不通过的话则会继续收到401/407或403，这时UAC必须不能再次使用刚才被拒绝的信任书进行尝试，需要重新生成请求直至UA/Proxy认证通过。注意也可以第一次请求时就已经带有认证信息。

    当UAC在接收到401（Unauthorized）或者407（ProxyAuthenticationRequired）应答之后，重新用它的信任书来提交请求，它必须增加Cseq头域的值，就像发送一个正常的新请求一样。

    如果认证通过的话，UA应当把这个给特定To头域和”realm”字段的信任书cache起来，以备给这个地址下一个请求时候使用。

    我们建议使用下列步骤来cache一个proxy的信任书：如果UA在给特定Call-ID的请求的401/407应答中，接收到一个Proxy-Authenticate头域，它应当合并对这个realm的信任书，并且为以后具有相同Call-ID的请求发送这个信任书。这些信任书必须在对话中被cache住；不过如果UA配置的是它自己的本地外发proxy，那么如果出现要求认证的情况，那么UA应当cache住跨对话的信任书。注意，这个意味着在一个对话中的请求可以包含在Route头域中所经过proxy都不需要的信任书。

    当服务器可以正确处理绝大部分SIP请求，有本文档约定了两类请求要求特别的认证处理：ACK和CANCEL。在某一个认证方案下，并且这个认证方案是使用应答来放置计算nonces（比如Digest），那么对于某些没有应答的情况，就会出现问题，比如ACK。所以，基于这个原因，一个服务器接受在INVITE请求中的信任书，也必须同样接收对应ACK的信任书。UAC通过赋值所有的INVITE请求中的Authorization和Proxy-Authorization头域值来创建一个相关的ACK消息。服务器必须接收这个ACK请求。

    虽然CANCEL方法具有应答（2xx），服务器必须不能拒绝CANCEL请求，因为这些请求不能被重新提交。通常，如果CANCEL请求和被CANCEL的请求来自同一个节点（假设某种通讯协议，或者网络层有安全关系26.2.1节描述），服务器应当接收CANCEL请求。

     可见SIP为认证系统提供了一个无状态的，试错机制，这个认证机制式基于HTTP的认证机制的。通过请求和回复来验证用户身份。

4. 认证消息解析

注：只讲述重要字段，细节查看RFC2617。

具体为401中的WWW-Authenticate应答头域，相对应的为请求的Authorization头域；407中的Proxy-Authenticate头域，相对应的是请求的Proxy-Authorization头域。

a) WWW-Authenticate/Proxy-Authenticate头域

这个头域值包含了至少一个表明认证方式和适用realm的参数的拒绝原因。

如：

      WWW-Authenticate: Digest

              realm="biloxi.com",

              qop="auth,auth-int",

              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

          opaque="5ccc069c403ebaf9f0171e9517f40e41"

i. Realm

realm字串单独定义被保护的区域。Realm字串必须是全局唯一的。我们强调这个realm字串必须包含一个主机名或者域名。Realm字串应当是一个可读的能够展示给用户的字串。

通常，SIP认证对于特定realm（一个保护区域）是有意义的。因此，对于Digest认证来说，每一个类似的保护区域都有自己的用户名和密码集合。

ii. Nonce

服务器端指定的数据字符，它应在每个401回应产生时，被唯一地创建。建议该字符以base64方式或16进制方式出现。另外，该字符在标题行中传递时是在引号内的，因此允许使用双引号字符。

iii. Stale

　　一个标志，用来指示客户端先前的请求因其nonce值过期而被拒绝。如果stale是TRUE（大小写敏感），客户端可能希望用新的加密回应重新进行请求，而不用麻烦用户提供新的用户名和口令。服务器端只有在收到的请求nonce值不合法，而该nonce对应的摘要（digest）是合法的情况下（即客户端知道正确的用户名/口令），才能将stale置成TRUE值。如果stale是FALSE或其它非TRUE值，或者其stale域不存在，说明用户名、口令非法，要求输入新的值。

iv. Algorithm

Algorithm是个字符串，用来指示用来产生摘要及校验和的算法对。如果该域没指定，则认为是“MD5“算法。如果该域指定的算法无法理解，该质询（challenge）将被忽略。

v. qop

“auth”表示鉴别方式；“auth-int”表示鉴别保护的完整性。

vi. opaque

由服务器指定的字符串，客户端不能改动它，如果并发请求的URI也指向同一个受保护区间，则该信息将被加在这些请求的授权标题域中返给服务器。建议采用base64或16进制的字符串。

b) Authorization/Proxy-Authorization头域

该头域包含了具有这个UA到请求的资源所在的realm（区域）的信任书和所需要的认证支持的参数和重现保护的参数。

例子：

      Authorization: Digest username="bob",

              realm="biloxi.com",

              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

              uri="sip:bob@biloxi.com",

              qop=auth,

              nc=00000001,

              cnonce="0a4f113b",

              response="6629fae49393a05397450978507c4ef1",

          opaque="5ccc069c403ebaf9f0171e9517f40e41"

如果服务器对特定请求没有要求认证或对于特定realm没有对应的认证信息，那么使用缺省的用户名,”anonymous”,并且这个用户名没有密码（密码是””）。

根据RFC2617，合法的回应包含对用户名、口令、给定nonce值、SIP方法、请求URI的校验和（checksum，缺省是MD5的校验和）。

i. Response

是个字符串，由32个经过计算的16进制数字组成，用来证明用户是否知道口令。

ii. Cnonce

当qop指示发送了，该指示必须要指定，而当服务器端没有在WWW-鉴别（WWW- Authenticate）标题域中添加qop指示时，该指示一定不能指定。cnonce-value是客户端提供的字符串，它由客户端和服务器共同使用，用来避免选择纯文本攻击、提供共同鉴别、提供某些消息的完整性保护。

5. 摘要的计算方法

128位的MD5摘要由32个可打印的ASCII码字符表示。128位摘要中的位按其重要性由高到低转换，在某个时刻每4位可用下面的ASCII表示。每4位都可用16进制字符‘0123456789abcdef’表示，也就是说，二进制0000由字符‘0’表示；0001由字符‘1’表示，以后如此类推，1111用‘f’表示。

在本文中，用KD（secret,data）来表示摘要算法，其中data指数据，secret表示采用的方法.如果表示校验和算法时，data要写成H（data）；而unq（X）表示将带引号字符串的引号去掉。

简单来说,response =

H(H(username:realm:password)：nonce：cnonce：H(requestMothod:request-URI))

以下为详细的计算规则.

对于"MD5" 和"MD5-sess" 算法：

H()：hash函数

H(data) = MD5(data)

和

KD(secret, data) = H(concat(secret, ":", data))

也就是说，摘要（digest）就是对secret与data通过冒号连接一起的结果进行MD5运算。而"MD5-sess"算法则允许其它第三方服务器参与鉴别。

a) 请求－摘要（Request-Digest）

　　 如果”qop”值是"auth" 或"auth-int"：

　　request-digest = <"> < KD ( H(A1), unq(nonce-value)

　　 ":" nc-value

　　 ":" unq(cnonce-value)

　　 ":" unq(qop-value)

　　 ":" H(A2)

　　 ) <">

　　 如果”qop”指示没有给出（与RFC2069保持兼容性）：

　　request-digest =<"> < KD ( H(A1), unq(nonce-value)

　　":" H(A2)

　　) <">

　　 A1及A2的定义在下面。

b) A1

　　 如果算法（"algorithm"）值是”MD5”或没有指定，则A1是：

　　A1 = unq(username-value) ":" unq(realm-value) ":" passwd

　　其中

　　passwd = < user's password >

　　如果"algorithm"值是"MD5-sess"，则A1只要计算一次，即当客户端发出第一个请求，并从服务器收到WWW-鉴别（WWW-Authenticate）质询（challenge）时计算。它使用该质询中的服务器的nonce，则用来构建A1的第一个客户端nonce值应为：

　　A1 = H( unq(username-value) ":" unq(realm-value)

　　 ":" passwd )

　　 ":" unq(nonce-value) ":" unq(cnonce-value)

　　 上式为并发请求和回应的鉴别产生一个‘会话密钥’（session key），该密钥对于每个‘鉴别会话’（authentication session）都是不同的，这样，就限制了使用任何一个密钥进行哈希处理的次数。

c) A2

如果”qop”值是”auth”或者没给出，则A2：

A2 = Method ":" digest-uri-value　

如果"qop"值是"auth-int", 则A2：

A2 = Method ":" digest-uri-value ":" H(entity-body)

d) 指示值和带引号的字符串（Directive values and quoted-string）

注意，许多指示的取值，如”username-value”等，被定义成带引号的字符串（quoted-string）。而实际上，”unq”注释则表示在生成字符串A1时，去掉其外部的引号。因而，如当授权标题包括该域，如：

　　username="Mufasa", realm=myhost@testrealm.com

则表示用户Mufasa的口令是"Circle Of Life"，这样H（A1）就可表示成

　　H（Mufasa:myhost@testrealm.com:Circle Of Life），注意，在摘要字符串中没有引号。

　　注意，在摘要函数H（）中的字符串中不允许出现空格，除非空格出现在带引号的字符串内或者用以标记字符串摘要的实体主体中。例如，上面出现的字符串A1必须是

　　Mufasa:myhost@testrealm.com:Circle Of Life

在冒号的两边都不可以有空格，但是允许口令单词之间出现空格（Circle+SP+Of+SP+Life）。同样，其它由H（）摘要的字符串也不能在用于域间分隔的冒号两边加空格，除非空格在引号内或被摘要的实体主体内。

　　 同样要注意的是，如果应用了完整性保护（integrity protection），即qop=auth-int，则H（实体-主体）就是实体主体的哈希值，而不是消息主体的哈希值，该值在发送方进行任何传输编码前计算，之后，被接收方删除。

 

http://blog.sina.com.cn/s/blog_4b839a1b01000bqq.html

 

HTTP摘要认证

摘要访问认证是一种协议规定的Web服务器用来同网页浏览器进行认证信息协商的方法。它在密码发出前，先对其应用哈希函数，这相对于HTTP基本认证发送明文而言，更安全。

从技术上讲，摘要认证是使用随机数来阻止进行密码分析的MD5加密哈希函数应用。它使用HTTP协议。

目录

[隐藏] 

• 1 概述
• 2 MD5 安全问题对摘要认证的影响
• 3 HTTP摘要认证的考虑
  • 3.1 优势
  • 3.2 劣势
  • 3.3 可替代的认证协议
• 4 示例及说明
• 5 SIP 摘要认证
• 6 浏览器实现
• 7 参见
• 8 参考
• 9 外部链接

概述[编辑]

摘要访问认证最初由 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)。这就允许一些实现（如，JBossDIGESTAuth)仅存储 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: localhost
Authorization: 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 值由三步计算而成。当多个数值合并的时候，使用冒号作为分割符。

1. 对用户名、认证域(realm)以及密码的合并值计算 MD5 哈希值，结果称为 HA1。
2. 对HTTP方法以及URI的摘要的合并值计算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，结果称为 HA2。
3. 对 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。

SIP 摘要认证[编辑]

SIP基本上使用了同样的摘要认证算法。它由 RFC 3261 定义。

浏览器实现[编辑]

大多数浏览器都基本上实现了该协议，除了某些特性，比如检查auth-int、或者MD5-sess算法。如果服务器要求处理这类可选特性，客户端可能无法进行认证（虽然需要注意的是，Apache服务器的mod_auth_digest模块也没有完全实现 RFC 2617）。

• Amaya
• 基于Gecko: (不包括 auth-int: [1])
  • Mozilla Application Suite
  • Mozilla Firefox
  • Netscape 7+
• iCab 3.0.3+
• 基于KHTML- 及 WebKit: (不包括 auth-int [2])
  • iCab 4
  • Konqueror
  • Google Chrome
  • Safari
• 基于Tasman:
  • Internet Explorer for Mac
• Trident-based:
  • Internet Explorer 7+ ^[4] (不包括 auth-int)
• 基于Presto:
  • Opera
  • Opera Mobile
  • Opera Mini
  • Nintendo DS 浏览器
  • Nokia 770 浏览器
  • Sony Mylo 1 的浏览器
  • Wii Internet Channel 浏览器

参见[编辑]

• 认证和密钥协商协议
• HTTP基本认证

参考[编辑]

1. ^ Hash Collision Q&A. (date unidentified) [2010-07-02]. （原始内容存档于2004-09-01）. 注意：没有给出具体信息；需要引用该页的准确的版本。
2. ^ http://tools.ietf.org/html/rfc2617#section-4.13
3. ^ http://www.w3.org/Protocols/HTTP/1.0/spec.html#Request
4. ^ http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#msie

外部链接[编辑]

• RFC 2617

http://zh.wikipedia.org/wiki/HTTP%E6%91%98%E8%A6%81%E8%AE%A4%E8%AF%81#SIP_.E6.91.98.E8.A6.81.