温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

HTTP认证模式:Basic & Digest

发布时间:2020-07-05 15:00:43 来源:网络 阅读:4156 作者:胡壮壮 栏目:建站服务器

一. Basic 认证

  客户端以“ : ”连接用户名和密码后,再经BASE64加密通过Authorization请求头发送该密文至服务端进行验证,每次请求都需要重复发送该密文。可见Basic认证过程简单,安全性也低,存在泄露个人账号信息以及其他诸多安全问题。以下仅为原理演示,不代表真实情况:

  1. 客户端向服务器请求数据:

    GET / HTTP/1.1
    Host: www.myrealm.com

  2. 服务端向客户端发送验证请求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

  3. 客户端收到401返回值后,将自动弹出一个登录窗口,等待用户输入用户名和密码

  4. 将“用户名:密码”进行BASE64加密后发送服务端进行验证:

    GET / HTTP/1.1
    Host: www.myrealm.com
    Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx

  5. 服务端取出Authorization请求头信息进行解密,并与用户数据库进行对比判断是否合法,合法将返回200 OK。RFC 2617 规格中Basic认证不发送Authentication-Info头部,Authentication-Info头部是Digest认证中新增的

HTTP认证模式:Basic & Digest

 1 <?php 2   if (!isset($_SERVER['PHP_AUTH_USER'])) { 3     header('WWW-Authenticate: Basic realm="My Realm"'); 4     header('HTTP/1.0 401 Unauthorized'); 5     echo 'Text to send if user hits Cancel button'; 6     exit; 7   } else { 8     echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>"; 9     echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";10   }

HTTP认证模式:Basic & Digest

  

二. 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的关联状态数据

  下面将就摘要计算方法进行说明: 

  1. 算法的一般性表示

    H(data) = MD5(data)
    KD(secret, data) = H(concat(secret, ":", data))
  2. 与安全信息相关的数据用A1表示,则

    a) 采用MD5算法:
        A1=(user):(realm):(password)
    b) 采用MD5-sess算法:
        A1=H((user):(realm):(password)):nonce:cnonce
  3. 与安全信息无关的数据用A2表示,则

    a) QoP为auth或未定义:
        A2=(request-method):(uri-directive-value)
    b) QoP为auth-int:
        A2=(request-method):(uri-directive-value):H((entity-body))
  4. 摘要值用response表示,则

    HTTP认证模式:Basic & Digest

    a) 若qop没有定义:
        response
        = KD(H(A1),<nonce>:H(A2))
        = H(H(A1),<nonce>:H(A2))
    b) 若qop为auth或auth-int:
        response
        = KD(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))
        = H(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))

    HTTP认证模式:Basic & Digest

     

三. 安全风险

  • 在线字典***(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认证。用户在所使用的认证机制中如何发现这一潜在***样式应该得到可见的帮助


向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI