一. Basic 认证

　　客户端以“ : ”连接用户名和密码后，再经BASE64编码( Base64 Content-Transfer-Encoding )通过Authorization请求头发送该密文至服务端进行验证，每次请求都需要重复发送该密文。可见Basic认证过程简单，安全性也低，存在泄露个人账号信息以及其他诸多安全问题，最好在实现了Transport Layer Security (TLS)的情况下去使用。以下仅为原理演示，不代表真实情况：

1. 客户端向服务器请求数据:

   GET / HTTP/1.1
   Host: www.myrealm.com

2. 服务端向客户端发送验证请求401：

   HTTP/1.1 401 Unauthorised
   Server: bfe/1.0.8.18
   WWW-Authenticate: Basic realm="myrealm.com"
   Content-Type: text/html; charset=utf-8

3. 客户端收到401返回值后，将自动弹出一个登录窗口，等待用户输入用户名和密码
4. 将“用户名:密码”进行BASE64加密后发送服务端进行验证：

   GET / HTTP/1.1
   Host: www.myrealm.com
   Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx

5. 服务端取出Authorization请求头信息进行解密，并与用户数据库进行对比判断是否合法，合法将返回200 OK。RFC 2617 规格中Basic认证不发送Authentication-Info头部，Authentication-Info头部是Digest认证中新增的

二. Digest 认证

　　Digest认证试图解决Basic认证的诸多缺陷而设计，用户密码在整个认证过程中是个关键性要素。

　　下为服务端发送的Digest认证响应头部实例及各指令含义说明：(如果你做PHP开发，其官方文档中发送WWW-Authenticate头部时可能各指令之间用了空格，在Chrome下是不会弹出认证对话框的，应该换成”, “或”,“)

WWW-Authenticate: Digest realm="Restricted area", qop="auth,auth-int", nonce="58e8e52922398", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", algorithm="MD5"

• WWW-Authenticate：服务端发送的认证质询头部
• Authentication-Info：服务端发送的认证响应头部，包含nextnonce、rspauth响应摘要等
• realm：授权域，至少应该包含主机名
• domain：授权访问URIs列表，项与项之间以空格符分隔
• qop：质量保护，值为auth或auth-int或[token]，auth-int包含对实体主体做完整性校验

• nonce：服务端产生的随机数，用于增加摘要生成的复杂性，从而增加破解密码的难度，防范“中间人”与“恶意服务器”等攻击类型，这是相对于不使用该指令而言的；另外，nonce本身可用于防止重放攻击，用于实现服务端对客户端的认证。RFC 2617 建议采用这个随机数计算公式：nonce = BASE64(time-stamp MD5(time-stamp “:” ETag “:” private-key))，服务端可以决定这种nonce时间有效性，ETag(URL对应的资源Entity Tag，在CGI编程中通常需要自行生成ETag和鉴别，可用于鉴别URL对应的资源是否改变，区分不同语言、Session、Cookie等)可以防止对已更新资源版本(未更新无效，故需要设定nonce有效期)的重放请求，private-key为服务端私有key

• opaque：这是一个不透明的数据字符串，在盘问中发送给客户端，客户端会将这个数据字符串再发送回服务端器。如果需要在服务端和客户端之间维护一些状态，用nonce来维护状态数据是一种更容易也更安全的实现方式
• stale：nonce过期标志，值为true或false
• algorithm：摘要算法，值为MD5或MD5-sess或[token]，默认为MD5

　　下为客户端发送的Digest认证头请求部实例及各指令含义说明：

Authorization: Digest username="somename", realm="Restricted area", nonce="58e8e52922398", uri="/t.php", response="9c839dde909d270bc5b901c7f80f77d5", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", qop="auth", nc=00000001, cnonce="9c30405c3a67a259"

• cnonce：客户端产生的随机数，用于客户端对服务器的认证。由于“中间人”与“恶意服务器”等攻击方式的存在，导致一个特意选择而非随机唯一的nonce值传给客户端用于摘要的计算成为可能，使得“选择性明文攻击”可能奏效，最后用户密码泄露。因此与nonce一样，cnonce可用于增加摘要生成的复杂性，从而增加破解密码的难度，也就保证了对服务端的认证

  The countermeasure against this attack(选择明文攻击) is for clients to be configured to require the use of the optional "cnonce" directive;this allows the client to vary the input to the hash in a way not chosen by the attacker.

• nc：当服务端开启qop时，客户端才需要发送nc(nonce-count)。服务端能够通过维护nc来检测用当前nonce标记的请求重放。如果相同的nc出现在用当前nonce标记的两次请求中，那么这两次请求即为重复请求。所以对于防止重放攻击而言，除了nonce之外，nc才是最后的保障。因此服务端除了维护用户账号信息之外，还需要维护nonce和nc的关联状态数据

　　下面将就摘要计算方法进行说明：

1. 算法的一般性表示

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

2. 与安全信息相关的数据用A1表示，则

   a) 采用MD5算法：A1=(user):(realm):(password)
   b) 采用MD5-sess算法：A1=H((user):(realm):(password)):nonce:cnonce

3. 与安全信息无关的数据用A2表示，则

   a) QoP为auth或未定义：A2=(request-method):(uri-directive-value)
   b) QoP为auth-int：A2=(request-method):(uri-directive-value):H((entity-body))

4. 摘要值用response表示，则

   a) 若qop没有定义：response= KD(H(A1),<nonce>:H(A2))= H(H(A1),<nonce>:H(A2))
   b) 若qop为auth或auth-int:response= KD(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))= H(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))

三. 安全风险

• 在线字典攻击(Online dictionary attacks)：攻击者可以尝试用包含口令的字典进行模拟计算response，然后与窃听到的任何nonce / response对进行对比，若结果一致则攻击成功。为应对针对弱口令的字典攻击，降低攻击成功的可能性，可以禁止用户使用弱口令
• 中间人(Man in the Middle)：在一次中间人攻击中，一个弱认证方案被添加并提供给客户端，因此你总是应该从多个备选认证方案中选择使用最强的那一个；甚至中间人可能以Basic认证替换掉服务端提供的Digest认证，从而窃取到用户的安全凭证，然后中间人可利用该凭证去响应服务端的Digest认证盘问；攻击者还可能打着免费缓存代理服务的幌子来招揽轻信者，通过实施中间人攻击，盗取他们的安全凭证；中间代理也可能诱导客户端来发送一个请求给服务端。为此，客户端可考虑给出安全等级风险警示，或在跟踪服务端的认证配置时发现其认证强度降低就发出警告，或配置成只使用强认证，或从指定站点来完成认证
• 预先计算字典攻击(Precomputed dictionary attacks)：攻击者先构建(response, password) 对字典，然后用选择性明文(nonce)攻击的办法来获得相应盘问的response，检索字典找到匹配的response则攻击成功
• 批量式暴力攻击(Batch brute force attacks)：中间人会对多个用户执行选择性明文攻击来搜集相应的responses，通过控制搜集的nonce / response对的数量将会缩短找到第一个password的耗时，这种攻击的应对之策就是要求客户端使用cnonce指令

• 假冒服务器欺骗(Spoofing by Counterfeit Servers)：对于Basic认证，这种攻击方式更容易奏效，对于Digest认证则更难，但前提是客户端必须知道将要使用的是Digest认证。用户在所使用的认证机制中如何发现这一潜在攻击样式应该得到可见的帮助