Http authentication（BASIC, DIGEST）

標籤：basic   ges   擴充   family   call   and   大學   user   作用   

Http authentication....BASIC:

In the context of an HTTP transaction, basic access authentication is a method for a web browser or other client program to provide a user name and password when making a request.[1]

Before transmission, the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm. For example, given the user name ‘Aladdin‘ and password ‘open sesame‘, the string ‘Aladdin:open sesame‘ is Base64 encoded, resulting in ‘QWxhZGRpbjpvcGVuIHNlc2FtZQ==‘. The Base64-encoded string is transmitted in the HTTP header and decoded by the receiver, resulting in the colon-separated user name and password string.

While encoding the user name and password with the Base64 algorithm makes them unreadable to the unaided eye, they are as easily decoded as they are encoded. Security isnot the intent of the encoding step. Rather, the intent of the encoding is to encode non-HTTP-compatible characters that may be in the user name or password into those that are HTTP-compatible.

One advantage of the basic access authentication is all web browsers support it. Rarely it is used on publicly accessible Internet web sites but may sometimes be used by small, private systems. A later mechanism, digest access authentication, was developed in order to replace the basic access authentication and enable credentials to be passed in a relatively secure manner over an otherwise unsecure channel. Http authentication.....DIGEST:

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials with a user‘s web browser. It uses encryption to send the password over the network, which is safer than the Basic access authentication that sends plaintext.

Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. It uses the HTTP protocol.

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes.Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication. 

HTTP協議(RFC2616)的兩種認證機制(Basic和Digest)  SIP類似Http協議。其認證模式也一樣。Http協議（RFC 2616 ）規定可以採用Basic模式和摘要模式（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== 【虎.無名，格式如Authorization:Basic base64(username:password)。。。但是沒定義如何處理realm資訊，簡單處理，可以針對每個realm分別有一組user:pass資訊。進一步，可以走md5摘要，但這些已經超出標準，估計不被瀏覽器支援。】  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"

http://blog.sina.com.cn/s/blog_721948c20100xw19.html

 

Http authentication（BASIC, DIGEST）