RFC 6331翻译，关于废弃RFC2831的digest authentication - tRavAsty/SASL GitHub Wiki

##1.介绍和总览 RFC2831定义了如何使用HTTP中的摘要认证来作为SASL层的安全机制。它的目的既在于提高CRAM-MD5'['RFC2195']'的安全性，也在于给web，email，LDAP和其他协议提供一个便捷的单独的认证机制。尽管可以认为DIGEST-MD5的安全性比CRAM-MD5高，但是许多开发者认为DIGEST-MD5额外的复杂性让它非常难以全面的实施，因此安全性就得不到保障

一下就是DIGEST-MD5的一些不足的地方的列表

1.这个机制有太多的选项和模式

2.使用了老版本的ABNF，老版本的ABNF允许额外折叠空白(?)，而新的版本并不使用 因此，这个功能被很多开发者禁止

3.DIGEST-MD5使用realm来定义一系列账户 一个DIGEST-MD5服务器可以支持一个或者多个域。DIGEST-MD5的文件并没有指出域的名字应该被怎样命名，更重要的是，没有指出域应该怎么进入用户接口(User Interfaces)。因此，很多DIGEST-MD5客户端有着令人困惑的UI，不允许用户输入域，也不允许用户选择一个服务器支持的域

4.在内部的哈希中使用用户名是有问题的 DIGEST-MD5内部的哈希是MD5对冒号分割的用户名，域，和密码。存储的是他们的哈希而不是清楚的明文。这种方法是有一些有用的功能，像是保护有着相同用户名的认证服务器。然而，这个功能很少在实际中被使用。首先，内部哈西和广泛使用夫人Unix 密码数据库并不兼容，并且，用户名的改变会使得内部的哈希值无效。

5.DES/3DES和RC4安全层的描述是不够产生一个能够独立操作的互操作接口

6.DIGEST-MD5的外部哈希并不保护整个认证交换，这使得该机制非常容易受到中间人攻击 比如提供一个篡改过的支持的qop和密码的列表

7.DIGEST-MD5没有以下特征，使得它在协议中不安全 A.信道绑定 B.哈希模块化(hash agility)，比如说很难用别的哈希算法代替MD5 C.对SASLPrep以及其他Unicode字符的用户名和密码的支持。原始的DIGEST-MD5在SASLPrep之前而且并不推荐任何的Unicode标准

8.DIGEST-MD5加密的原语已经跟不上今天的时代的标准 A.MD5已经足够脆弱到使用暴力破解攻击了 B.RC4加密在安全层使用的时候没有抛弃初始密钥流产出的情况下易于被攻击 C.DES因为过小的密钥空间已经被认为是不安全的了

上面所提到的问题已经出现在HTTP 摘要认证机制中了

虽然DIGEST-MD5是扩展机制，上述问题可以被修改，但是修改对于一个原本就很复杂的机制来说，会带来操作上更大的复杂性。此外，一个修改过的机制可能与别的机制的互操作性不兼容而且易于遭受降级攻击

The Salted Challenge Response Authentication Mechanism家族已经被开发，而且提供了和DIGEST-MD5相似的功能，但这个机制被设计的更好