周海漢 2006.7.11 [email protected]

SIP類似Http協議。其認證模式也一樣。Http協議（RFC 2616 ）規定可以採用Base模式和摘要模式（Digest schema）。RFC 2617 專門對兩種認證模式做了規定。RFC 1321 是MD5標準。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=”[email protected]” 證書：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採用一樣的認證。如果為空或忽略則為整個伺服器。 nonce：隨機字串，每次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=”[email protected]”, qop=”auth,auth-int”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093”, opaque=”5ccc069c403ebaf9f0171e9517f40e41” 再次請求： Authorization: Digest username=”Mufasa”, realm=”[email protected]”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093”, uri=”/dir/index.html”, qop=auth, nc=00000001, cnonce=”0a4f113b”, response=”6629fae49393a05397450978507c4ef1”, opaque=”5ccc069c403ebaf9f0171e9517f40e41” 4.比較基本認證和摘要訪問認證都是很脆弱的。基本認證可以讓竊聽者直接獲得使用者名稱和密碼，而摘要訪問認證竊聽者只能獲得一次請求的文件。

如非註明轉載, 均為原創. 本站遵循知識共享CC協議,轉載請註明來源