这是网络系列的第十篇文章,接下来会有更多精彩内容.敬请期待! 让我们一起乘风破浪!
前言
上篇中我们了解到了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的最初设想还是多方面的, 只是没有对应时代的需求啊.
注
部分图片来源于网络，如有侵权，请告知。
如有错误，还请指出。共勉！
您的喜欢是最大的赞赏。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
