6.2.1 HTTP Basic、HTTP Digest 与 NTLM 认证

Basic、Digest 与 NTLM 认证都是基于用户名/密码的认证

HTTP Basic

明文传送的用户名与密码信息很容易被拦截和篡改。 然而， 如果搭配 SSL， 那么这些弱点也是可以接受的

HTTP Digest

是一种更加安全的认证形式， 在传输密码前会对其进行 MD5 哈希处理， 同时会配以密码随机数。 密码随机数是个随机数或伪随机数， 用于消息进行签名， 不过每个值只能使用一次。 由于每个随机数只会使用一次， 然后就会被标记为过期， 因此可以防止重放攻击（重新发送之前的密文). HTTP Basic 与 HTTP Digest 认证现在已经合并成一个标准， 即 RFC2617(http://tools.ietf.org/html/rfc2617)

NTLM

微软推出的安全协议， 提供了认证、完整性与加密服务。 NTLM 认证是一项类似于 HTTP Basic 与 HTTP Digest 认证的挑战 - 响应协议。 它在很大程度上已经被 Kerberos 系统取代， 不过依然还继续用于 Web 上的远程用户。 Kerberos 是由 MIT 基于 “tickets" 想法而开发出来的认证协议， 可以在不安全的网络上实现安全的身份识别

NSURLConnection 会完成各种认证方式的随机数与哈希值的处理工作， 这样只需以 NSURLCredential 对象的形式指定认证信息就可以了。 NSURLCredential 适合于大多数的认证请求， 因为它可以表示由用户名/密码组合、客户端证书以及服务器信任创建的认证信息。认证信息有各种持久化选项： 不持久化、只对当前会话持久化以及永久持久化。应用只能访问由它们创建的认证信息，用户可以授权要访问的应用，这一点与传统的 Mac 开发是类似

处理 Basic 认证挑战

在确定挑战是针对 HTTP Basic 或另一种支持的挑战类型后， 应该确保挑战没有失败， 并使用用户输入的用户名与密码创建 NSURLCredential 对象. 如果挑战失败, 那就警告用户并取消挑战. 这是非常重要的, 因为 willSendRequestForAuthenticationChallenge: 可能会被调用多次. 根据配置, 如果用户的认证信息不合法而又没有恰当地进行检查, 那就有可能在用户只提交一次不合法的认证信息后, 账户就被锁定了. 如果进来的挑战认证方法并不是应用所能处理的类型, 那就不要发出响应. 这会告诉 NSURLConnection, 应用无法处理这种认证方法