close

HTTP 的認證模式


  SIP類似HTTP協定。其認證模式也一樣。HTTP協定(RFC 2616 )規定可以採用Base模式和摘要模式(Digest schema)RFC 2617 專門對兩種認證模式做了規定。RFC 1321MD5標準。Digest對現代密碼破解來說並不健全,但比基本模式還是好很多。MD5已經被山東大學教授找到方法可以仿冒(我的理解),但現在還在廣泛使用。

1.最簡單的攻擊方式

  如果網站要求認證,客戶端端發送明文的使用者名密碼,那網絡上的竊聽者可以輕而易舉的獲得使用者名密碼,起不到安全作用。我上學時曾在科大實驗室局域網內竊聽別人的科大BBS的密碼,發現BBS的使用者名密碼居然是明文傳輸的。那種做賊的心虛和做賊的興奮讓人激動莫名。偷人錢財會受到道德譴責,偷人密碼只會暗自得意忘形。比「竊書不算偷」還沒有罪惡感。因此你的使用者名和密碼明文傳輸的話,無異將一塊肥肉放在嘴饞的人面前。現在很多ASP網站的認證都將使用者名和密碼用MD5加密。MD5是將任意長度的字串和128位的隨機數字運算後生成一個16byte的加密字串。因此竊聽者抓住的是一團亂碼。但是,這有一個問題:如果竊聽者就用這團亂碼去認證,還是可以認證通過。因為伺服器將使用者名密碼MD5加密後得到的字串就是那一團亂碼,自然不能區別誰是合法使用者。這叫重放攻擊(replay attack)。這和HTTP的基本認證模式差不多。為了安全,不要讓別人不勞而獲,自然要做基本的防範。下面是HTTP協定規定的兩種認證模式。

2.基本認證模式

  客戶端向伺服器發送請求,伺服器返回401(未授權),要求認證。401消息的頭裡面帶了質詢息。realm用以區分要不同認證的部分。客戶端端收到401後,將使用者名密碼和質詢訊息用BASE64加密形成證書,發送回伺服器認證。語法如下:

      challenge   = "Basic" realm
      credentials = "Basic" basic-credentials

示例

   認證標頭: WWW-Authenticate: Basic realm="zhouhh@mydomain.com"
   憑證:Authorization: Basic QsdfgWGHffuIcaNlc2FtZQ==


3.摘要存取認證

  為了防止重放攻擊,採用摘要存取認證。在客戶端發送請求後,收到一個401(未授權)消息,包含一個質詢(Challenge)。消息裡面有一個唯一的字串:nonce,每次請求都不一樣。客戶端將使用者名密碼和401消息返回的挑戰一起加密後傳給伺服器。這樣即使有竊聽,他也無法通過每次認證,不能重放攻擊。Http並不是一個安全的協定。其內容都是明文傳輸。因此不要指望Http有多安全。


語法

      challenge        =  "Digest" digest-challenge

      digest-challenge  = 1#( realm | [ domain ] | nonce |
                          [ opaque ] |[ stale ] | [ algorithm ] |
                          [ qop-options ] | [auth-param] )


      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
      URI               = absoluteURI | abs_path
      nonce             = "nonce" "=" nonce-value
      nonce-value       = quoted-string
      opaque            = "opaque" "=" quoted-string
      stale             = "stale" "=" ( "true" | "false" )
      algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
                           token )
      qop-options       = "qop" "=" <"> 1#qop-value <">
      qop-value         = "auth" | "auth-int" | token


realm:讓客戶端知道使用哪個使用者名和密碼的字串。不同的領域可能密碼不一樣。至少告訴使用者是什麼主機做認證,他可能會提示用哪個使用者名登錄,類似一個Email。

domain:一個URI列表,指示要保護的域。可能是一個列表。提示使用者這些URI採用一樣的認證。如果為空或忽略則為整個伺服器。

noncenonce是一為數不小的亂數,長度在64到2048個位元之間,用來擔保session 的活性和每一個session的獨一無二性,其為一隨機字串,每次401都不一樣。跟算法有關。算法類似Base64加密:time-stamp H(time-stamp ":" ETag ":" private-key) 。time-stamp為伺服器時監標籤,ETag為請求的Etag。private-key為伺服器知道的一個值

opaque伺服器產生的由客戶端下去請求時原值返回。最好是Base64串或十六進制字串
auth-param為擴展用的,現階段忽略。
其他域請參考RFC2617。

授權頭語法

       credentials      = "Digest" digest-response
       digest-response  = 1#( username | realm | nonce | digest-uri
                       | response | [ algorithm ] | [cnonce] |
                       [opaque] | [message-qop] |
                           [nonce-count]  | [auth-param] )

       username         = "username" "=" username-value
       username-value   = quoted-string
       digest-uri       = "uri" "=" digest-uri-value
       digest-uri-value = request-uri   ; As specified by HTTP/1.1
       message-qop      = "qop" "=" qop-value
       cnonce           = "cnonce" "=" cnonce-value
       cnonce-value     = nonce-value
       nonce-count      = "nc" "=" nc-value
       nc-value         = 8LHEX
       response         = "response" "=" request-digest
       request-digest = <"> 32LHEX <">
       LHEX             =  "0" | "1" | "2" | "3" |
                           "4" | "5" | "6" | "7" |
                           "8" | "9" | "a" | "b" |
                           "c" | "d" | "e" | "f"

response加密後的密碼
digest-uri複製Request-Line,用於Proxy
cnonce如果qop設置,才設置,用於雙向認證,防止攻擊
nonce-count如果伺服器看到同樣的計數,就是一次重放

示例

401回應:        HTTP/1.1 401 Unauthorized
         WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
再次請求
         Authorization: Digest username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"

4.比較基本認證和摘要存取認證都是很脆弱的。基本認證可以讓竊聽者直接獲得使用者名和密碼,而摘要存取認證竊聽者只能獲得一次請求的檔案。

 

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 Bluelove1968 的頭像
    Bluelove1968

    藍色情懷

    Bluelove1968 發表在 痞客邦 留言(0) 人氣()