HTTP认证模式:Basic&Digest
一. Basic 认证
创新互联专注于企业成都营销网站建设、网站重做改版、且末网站定制设计、自适应品牌网站建设、成都h5网站建设、商城开发、集团公司官网建设、成都外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为且末等各大城市提供网站开发制作服务。
客户端以“ : ”连接用户名和密码后,再经BASE64加密通过Authorization请求头发送该密文至服务端进行验证,每次请求都需要重复发送该密文。可见Basic认证过程简单,安全性也低,存在泄露个人账号信息以及其他诸多安全问题。以下仅为原理演示,不代表真实情况:
客户端向服务器请求数据:
GET / HTTP/1.1
Host: www.myrealm.com服务端向客户端发送验证请求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客户端收到401返回值后,将自动弹出一个登录窗口,等待用户输入用户名和密码
将“用户名:密码”进行BASE64加密后发送服务端进行验证:
GET / HTTP/1.1
Host: www.myrealm.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx服务端取出Authorization请求头信息进行解密,并与用户数据库进行对比判断是否合法,合法将返回200 OK。RFC 2617 规格中Basic认证不发送Authentication-Info头部,Authentication-Info头部是Digest认证中新增的
1 Hello {$_SERVER['PHP_AUTH_USER']}."; 9 echo "You entered {$_SERVER['PHP_AUTH_PW']} as your password.
";10 }
二. 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的关联状态数据
下面将就摘要计算方法进行说明:
算法的一般性表示
H(data) = MD5(data) KD(secret, data) = H(concat(secret, ":", data))
与安全信息相关的数据用A1表示,则
a) 采用MD5算法: A1=(user):(realm):(password) b) 采用MD5-sess算法: A1=H((user):(realm):(password)):nonce:cnonce
与安全信息无关的数据用A2表示,则
a) QoP为auth或未定义: A2=(request-method):(uri-directive-value) b) QoP为auth-int: A2=(request-method):(uri-directive-value):H((entity-body))
摘要值用response表示,则
a) 若qop没有定义: response = KD(H(A1),
:H(A2)) = H(H(A1), :H(A2)) b) 若qop为auth或auth-int: response = KD(H(A1), : : : :H(A2)) = H(H(A1), : : : :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认证。用户在所使用的认证机制中如何发现这一潜在***样式应该得到可见的帮助
当前名称:HTTP认证模式:Basic&Digest
链接分享:http://cdiso.cn/article/jsoihc.html