【读】这一次,让咱们再深刻一点 - HTTP的摘要认证

这是网络系列的第十篇文章,接下来会有更多精彩内容.敬请期待! 让咱们一块儿乘风破浪!

前言

上篇中咱们了解到了HTTP认证框架中的基本认证. 它是基于质询/响应模型的.这篇中, 咱们粗略的了解下另外一种认证协议: 摘要认证. 固然摘要认证也不是最安全的认证方式, 而且至今没有普遍运用. 可是其相关概念仍是值得学习的.下面进入正文!

摘要认证的改进

摘要认证是HTTP支持的另外一种认证协议, 其试图修复基本认证的缺陷. 改进以下:

• 不会以明文的方式发送密码.
• 能够防止恶意用户捕获和重放认证的握手过程.
• 能够有选择的防止对报文内容的篡改.
• 防范其余几种常见的攻击方式.

以摘要保护密码

摘要认证遵循的谏言是"毫不经过网络发送密码". 客户端不会直接发送密码, 而是发送密码的"指纹"或"摘要"(能够理解为密码通过加密过的东西, 它是不可逆的).对比基本认证过程, 一块儿来看下摘要认证的过程:

由上面的过程, 能够看到, 客户端和服务器在知道用户名的状况下经过摘要进行认证, 没有传输密码. 第三方也就没法获取用户密码. 从而保护了密码的安全.

单向摘要

经常使用来生成摘要的方法是使用MD5, 这是一个单向的, 不可逆的过程. 它会对不肯定的输入, 产生固定128位的输出, 表示输入信息的摘要.一般, 128位的信息会以32位的十六进制表示.

用随机数防止重放攻击

你可能会想到, 第三方能够获取摘要, 以经过服务器的认证. 因此, 这里加入了"随机数"来防止这种状况的出现. 服务器在质询时向客户端发送随机数, 客户端在生成摘要时须要使用到它. 固然, 随机数是变化的, 这样能够有效的防止重放攻击.

摘要认证的握手机制

摘要认证是基本认证的升级版本, 所用的首部和基本认证大体相同, 只是增长了Authorization-Info首部, 服务器在认证经过后向客户端发送认证相关信息.

• 服务器在收到须要认证的请求后, 在(1)中生成随机数, 经过WWW-Authenticate首部发送给客户端(2).
• 在(3)中, 客户端选择摘要算法, 经过密码和其余信息计算出摘要. 在(4)中经过Authorization首部发送给服务器. 若客户端须要服务器进行认证, 能够发送客户端随机数.
• (5)中, 服务器接收摘要, 计算本身的摘要, 并验证. 若客户端对服务器进行了摘要认证, 服务器会在(6)中发送计算的摘要, 客户端在接收到数据后就能够进行认证了.

摘要的计算

下面一块儿来了解下摘要时如何计算的

摘要算法的输入数据

• 单向散列函数H(d), 和摘要KD(s,d)组成的一对函数, 其中s表示密码, d表示数据.
• 一个保护了安全信息的数据块, 包括密码, 称为A1
• 一个保护了请求报文中非保密属性的数据块, 称为A2

使用H和KD处理A1和A2, 产生摘要.

算法H(d)和KD(s, d)

摘要认证支持多种算法, 可是文档RFC 2617建议使用MD5和MD5-sess, 若没有指定算法, 默认采用MD5.具体以下:

H(d) = MD5(d)
KD(s, d) = H(concatenate(s:d))
复制代码

与安全性相关的数据A1

A1的生成和算法有关, 根据RFC 2617, 有以下规则:

• MD5算法A1的构成:

  A1 = <user>:<realm>:<password>
  复制代码

• MD5-sess算法A1的构成:

  A1 = MD5(<user>:<realm>:<password>):<nonce><cnone>
  其中, nonce表示当前随机数, cnone表示客户端随机数
  复制代码

与报文有关的相关数据A2

A2表示了和报文相关的信息, 好比URL, 请求方法, 报文主体等. A2有助于防止方法, 资源或报文被篡改.

RFC 2617说明, 根据选择的保护质量(qop), A2有两种策略:

• 当qop="auth"时, 只包含请求方法和URL.
• 当qop="auth-int"时, 不只含请求方法和URL, 还添加了报文主体部分.

qop	A2
auth	<\request-method> : <\uri>
auth-int	<\request-method> : <\uri> : H(request-body)

摘要算法总述

在了解了计算摘要所必须的元素后, 接下来了解下这个摘要最终是怎么计算的. 然而在计算最终结果时, 又出现了两种状况: 请求不包含qop(为了兼容以前的规范), 请求包含qop.

qop	计算方式	说明
未定义	KD(H(A1), <\nonce>:H(A2))	不推荐
auth 或 auth-int	KD(H(A1), <\nonce>:<\nc>:<\cnonce>:<\qop>:H(A2))	推荐

其中nc也是客户端发送的用于验证的数据.

摘要认证会话

客户端响应对对保护空间的WWW-Authenticate质询时, 会启动该保护空间的认证会话.在客户端收到另外一条来至保护空间的任意一台服务器的质询以前,认证会话一直持续. 客户端应该记住认证相关信息, 以便未来在此保护空间中构建请求的Authorization首部时使用.

在认证过时时, 客户端也可使用相关信息来构建请求首部, 而没必要让用户再次输入帐户和密码.

预受权

在普通的认证过程当中, 每一个请求都会有质询环节(参考下图的a).

而若是客户端在有过 请求质询的过程后, 事先知道认证须要的下一个随机数, 就能够直接发送带有 Authorization首部的请求, 这样就能够取消以后的 质询环节了(参考上图的b).

预受权对基本认证来讲并不重要(参考这里). 客户端在对某一个站点认证后, 在通过用户赞成能够记住用户名和密码, 下次再对这些站点认证时, 就能够直接发送用户名和密码了.

而对于摘要认证来讲, 假如了随机数来防止重放攻击. 服务器的随机数是任意的, 客户端在收到质询以前, 没法生成正确的Authorization首部.

为了进行预受权, 这里有三种生成随机数的方式, 客户端知道随机数后, 就能够生成正确的Authorization首部.

• 服务器在Authentication-Info首部预先发送下一个随机数.
• 服务器容许在一小段时间内使用相同随机数.
• 服务器和客户端使用同步的, 可预测的随机数生成算法.

对称认证

对称认证是指服务器对客户端发出质询后, 客户端也能够对服务器进行认证. 这需客户端发出客户端随机数, 服务器在计算摘要后, 经过Authorization-Info首部发送给客户端.

经过上文的了解, 生成摘要须要A2(它是与报文有关的相关数据), 包含了请求方法. 而相应报文中是没有请求方法的. 因此A2的肯定有不一样之处, 以下:

qop	A2
auth	: <\uri>
auth-int	: <\uri> : H(response-body)

须要注意的几个问题

多重质询

服务器在不知道客户端的具体能力时, 能够对客户端既发出基本认证质询,又发出摘要认证质询. 客户端在在面临多重质询时, 必须以它支持的最强的机制来应答.

差错处理

在摘要认证中, 客户端在请求时若某一个指令或其值使用不当, 或者缺乏某个指令, 服务器就应该以400 Bad request响应.

若是请求的摘要不匹配, 就应该记录一次登陆失败, 一客户端连续屡次失败, 可能存在攻击者在猜想密码.

服务器必定要肯定URL指令的值和请求行中的值相同.服务器也应该以400 Bad request响应.

保护空间

经过域能够将服务器的资源划分为不一样的保护空间. 每个保护空间都有本身的认证机制. 保护空间决定了能够自动应用证书的区域. 好比某条请求已经被受权, 再接下来的一段时间内, 该保护空间的其余请求也可使用该证书.若没有想过说明, 单个保护空间是不能扩展到其余范围的.

重写URI

若请求通过了代理, 而代理对URI进行了重写.这样就会破坏摘要认证.由于摘要认证会对URI进行检查.

结语

好了, 对于摘要认证就介绍到这里. HTTP原生认证的一些安全风险并未详细展开. 有兴趣的同窗能够继续研究下.经过学习, 能够发现HTTP的最初设想仍是多方面的, 只是没有对应时代的需求啊.

注

• 部分图片来源于网络，若有侵权，请告知。
• 若有错误，还请指出。共勉！
• 您的喜欢是最大的赞扬。