Http authentication（BASIC, DIGEST）

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="[e-mail]" 
證書：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="[e-mail]", 
qop="auth,auth-int", 
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 
opaque="5ccc069c403ebaf9f0171e9517f40e41" 
再次請求： 
Authorization: Digest username="Mufasa", 
realm="[e-mail]", 
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