• HTTP Digest authentication


    (Digest authentication是一个简单的认证机制最初是为HTTP协议开发的因而也常叫做HTTP摘要RFC2671中描写叙述。其身份验证机制非常easy,它採用杂凑式(hash)加密方法,以避免用明文传输用户的口令。

    摘要认证就是要核实,參与通信的两方,都知道两方共享的一个秘密(即口令)。

     

    当server想要查证用户的身份,它产生一个摘要盘问(digest challenge),并发送给用户。典型的摘要盘问例如以下:

     

    Digest realm="iptel.org", qop="auth,auth-int",

    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5

     

    这里包含了一组參数,也要发送给用户。用户使用这些參数,来产生正确的摘要回答,并发送给server。摘要盘问中的各个參数,其意义例如以下:

     

    realm(领域):领域參数是强制的,在全部的盘问中都必须有。它是目的是鉴别SIP消息中的机密。在SIP实际应用中,它通常设置为SIP代理server所负责的域名。

     

    在要求用户输入username和口令时,SIP用户代理则会显示这个參数的内容给用户,以便用户使用正确的username和口令(这个server的)。

     

    nonce(现时):这是由server规定的数据字符串,在server每次产生一个摘要盘问时,这个參数都是不一样的(与前面所产生的不会雷同)。现时一般是由一些数据通过md5杂凑运算构造的。

    这种数据通常包含时间标识和server的机密短语。这确保每一个现时都有一个有限的生命期(也就是过了一些时间后会失效,并且以后再也不会使用),并且是独一无二的

    (即不论什么其他的server都不能产生一个同样的现时)。

     

    client使用这个现时来产生摘要响应(digest response),这样server也会在一个摘要响应中收到现时的内容。server先要检查了现时的有效性后,才会检查摘要响应的其他部分。

     

    因而,现时在本质上是一种标识符,确保收到的摘要机密,是从某个特定的摘要盘问产生的。还限制了摘要盘问的生命期,防止未来的重播攻击。

    opaque(不透明体):这是一个不透明的(不让外人知道其意义)数据字符串,在盘问中发送给用户。

    在摘要响应中,用户会将这个数据字符串发送回给server。这使得server能够是无状态的。假设须要在盘问和响应之间维护一些状态,能够用这个參数传送状态给client,此后当摘要响应回来时,再读这个状态。

     

    algorithm(算法):这是用来计算杂凑的算法。当前仅仅支持MD5算法。

     

    qop(保护的质量)。这个參数规定server支持哪种保护方案。client能够从列表中选择一个。值

     auth表示仅仅进行身份查验, auth-int表示进行查验外,另一些完整性保护。须要看更具体的描写叙述,请參阅RFC2617。

     

    在收到了摘要盘问后,假设没有预先配置,用户代理软件一般会提示用户输入username和口令,产生一个摘要响应,并将这个响应发送给server。比如,摘要响应可能例如以下:

     

    Digest username="jan", realm="iptel.org",

    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org",

    qop=auth, nc=00000001, cnonce="0a4f113b",

    response="6629fae49393a05397450978507c4ef1", opaque=""

     

    摘要响应相似于摘要盘问。同样的參数则与摘要盘问有同样的意义。这里仅仅描写叙述新的參数:

    uri(统一资源指示符):这个參数包括了client想要訪问的URI。

    qop:client选择的保护方式。

     

    nc:现时计数器,这是一个16进制的数值,即client发送出请求的数量(包含当前这个请求),这些请求都使用了当前请求中这个现时值。比如,对一个给定的现时值,在响应的第一个请求中,client将发送nc=00000001。这个指示值的目的,是让server保持这个计数器的一个副本,以便检測反复的请求。假设这个同样的值看到了两次,则这个请求是反复的。

     

    cnonce:这也是一个不透明的字符串值,由client提供,而且client和server都会使用,以避免用明文文本。这使得两方都能够查验对方的身份,并对消息的完整性提供一些保护。

     

    response(响应):这是由用户代理软件计算出的一个字符串,以证明用户知道口令。

     

    当server接收到摘要响应,也要又一次计算响应中各參数的值,并利用client提供的參数值,和server上存储的口令,进行比对。假设计算结果与收到的客户响应值是同样的,则客户已证明它知道口令,

    因而客户的身份验证通过。`

     

     

  • 相关阅读:
    外文翻译 《How we decide》多巴胺的预言 第三节
    外文翻译 《How we decide》多巴胺的预言 第二节
    WPF学习12:基于MVVM Light 制作图形编辑工具(3)
    外文翻译 《How we decide》多巴胺的预言 第一节
    xcode上真机调试iphone4s出现“There was an internal API error.”解决方案
    cocos2d-x v2.2 IOS工程支持64-bit 遇坑记录
    简单优化:Zipalign
    Error: could not open `C:Javajre7libi386jvm.cfg
    【ios开发之疑难杂症】xcode运行出现SpringBoard 无法启动应用程序(错误:7)
    java IntelliJ IDEA 13 注册码 IDEA序列号 License Key
  • 原文地址:https://www.cnblogs.com/mengfanrong/p/4050445.html
Copyright © 2020-2023  润新知