Atitit HTTP 認證機制基本驗證 (Basic Authentication) 和摘要驗證 (Digest Authentication)attilax總結


 

Atitit HTTP 認證機制基本驗證 (Basic Authentication) 和摘要驗證 (Digest Authentication)attilax總結

 

1.1. 最廣泛使用的是基本驗證 (Basic Authentication) 和摘要驗證 (Digest Authentication)1

1.2. 關於HTTP AUTH的文檔不多。1

1.3. 什么是HTTP基本認證1

1.4. 適用場合 路由器 攝像頭2

1.5. 其他認證   除了基本認證(Basic Authentication), 還有摘要認證digest authentication, WSSE(WS-Security)認證4

1.6.   摘要訪問認證4

1.7. .服務器響應 服務端返回401未驗證的狀態,並且返回WWW-Authenticate信息,包含了驗證方式Digest,realm,qop,nonce,opaque的值。其中:4

1.8. 3.客戶端請求  (用戶名 "Mufasa", 密碼 "Circle Of Life")5

 

 

1.1. 最廣泛使用的是基本驗證 (Basic Authentication) 和摘要驗證 (Digest Authentication)

1.2. 關於HTTP AUTH的文檔不多。

RFChttp://www.ietf.org/rfc/rfc2617.txt

wikihttp://en.wikipedia.org/wiki/Basic_access_authentication

1.3. 什么是HTTP基本認證

  桌面應用程序也通過HTTP協議跟Web服務器交互, 桌面應用程序一般不會使用cookie, 而是把 "用戶名+冒號+密碼"BASE64算法加密后的字符串放在http request 中的header Authorization中發送給服務端, 這種方式叫HTTP基本認證(Basic Authentication)

  當瀏覽器訪問使用基本認證的網站的時候, 瀏覽器會提示你輸入用戶名和密碼,如下圖

 

使用HTTP AUTH需要在server端配置http auth信息(一般是webserver啟動的時候從配置文件里面讀取相關信息)。我用中文簡述一下http auth的過程:

· 客戶端發送http請求

· 服務器發現配置了http auth,於是檢查request里面有沒有"Authorization"http header

· 如果有,則判斷Authorization里面的內容是否在用戶列表里面,Authorization header的典型數據為"Authorization: Basic jdhaHY0=",其中Basic表示基礎認證, jdhaHY0=base64編碼的"user:passwd"字符串。

· 如果沒有,或者用戶密碼不對,則返回http code 401頁面給客戶端

· 標准的http瀏覽器在收到401頁面之后,應該彈出一個對話框讓用戶輸入帳號密碼;並在用戶點確認的時候再次發出請求,這次請求里面將帶上Authorization header

 

一次典型的訪問場景是:

· 瀏覽器發送http請求(沒有Authorization header

· 服務器端返回401頁面

· 瀏覽器彈出認證對話框

· 用戶輸入帳號密碼,並點確認

· 瀏覽器再次發出http請求(帶着Authorization header

· 服務器端認證通過,並返回頁面

· 瀏覽器顯示頁面

1.4. 適用場合 路由器 攝像頭

使用http auth的場景不會用cookie,也就是說每次都會送帳號密碼信息過去。然后我們都知道base64編碼基本上等於明文。這削弱了安全。

由於種種缺點,http auth現在用的並不多。不過在路由器等場合還是有應用的,原因是http auth最簡單,使用起來幾乎是零成本。

 

 

  BASIC認證概述

HTTP協議進行通信的過程中,HTTP協議定義了基本認證過程以允許HTTP服務器對WEB瀏覽器進行用戶身份證的方法,當一個客戶端向HTTP服務 器進行數據請求時,如果客戶端未被認證,則HTTP服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證,以決定用戶是否合法。客戶端在接收到HTTP服務器的身份認證要求后,會提示用戶輸入用戶名及密碼,然后將用戶名及密碼以BASE64加密,加密后的密文將附加於請求信息中, 如當用戶名為anjuta,密碼為:123456時,客戶端將用戶名和密碼用合並,並將合並后的字符串用BASE64加密為密文,並於每次請求數據 時,將密文附加於請求頭(Request Header)中。HTTP服務器在每次收到請求包后,根據協議取得客戶端附加的用戶信息(BASE64加密的用戶名和密碼),解開請求包,對用戶名及密碼進行驗證,如果用 戶名及密碼正確,則根據客戶端請求,返回客戶端所需要的數據;否則,返回錯誤代碼或重新要求客戶端提供用戶名及密碼。

 

二.   BASIC認證的過程

1  客戶端向服務器請求數據,請求的內容可能是一個網頁或者是一個其它的MIME類型,此時,假設客戶端尚未被驗證,則客戶端提供如下請求至服務器:

Get /index.html HTTP/1.0
Host:www.google.com

2  服務器向客戶端發送驗證請求代碼401,服務器返回的數據大抵如下:

HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm="google.com"
Content-Type: text/html
Content-Length: xxx

3  當符合http1.01.1規范的客戶端(如IEFIREFOX)收到401返回值時,將自動彈出一個登錄窗口,要求用戶輸入用戶名和密碼。

4  用戶輸入用戶名和密碼后,將用戶名及密碼以BASE64加密方式加密,並將密文放入前一條請求信息中,則客戶端發送的第一條請求信息則變成如下內容:

Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx

注:xxxx....表示加密后的用戶名及密碼。

5  服務器收到上述請求信息后,將Authorization字段后的用戶信息取出、解密,將解密后的用戶名及密碼與用戶數據庫進行比較驗證,如用戶名及密碼正確,服務器則根據請求,將所請求資源發送給客戶端:

 

三.         BASIC認證的缺點

HTTP基本認證的目標是提供簡單的用戶驗證功能,其認證過程簡單明了,適合於對安全性要求不高的系統或設備中,如大家所用路由器的配置頁面的認證,幾乎 都采取了這種方式。其缺點是沒有靈活可靠的認證策略,如無法提供域(domainrealm)認證功能,另外,BASE64的加密強度非常低,可以說僅 能防止sohu的搜索把它搜到了。當然,HTTP基本認證系統也可以與SSL或者Kerberos結合,實現安全性能較高(相對)的認證系統

 

1.5. 其他認證   除了基本認證(Basic Authentication), 還有摘要認證digest authentication, WSSE(WS-Security)認證

1.6.   摘要訪問認證

是一種協議規定的Web服務器用來同網頁瀏覽器進行認證信息協商的方法。它在密碼發出前,先對其應用哈希函數,這相對於HTTP基本認證發送明文而言,更安全。從技術上講,摘要認證是使用隨機數來阻止進行密碼分析的MD5加密哈希函數應用。它使用HTTP協議。

 

1.7. .服務器響應 服務端返回401未驗證的狀態,並且返回WWW-Authenticate信息,包含了驗證方式Digest,realm,qop,nonce,opaque的值。其中:

 

Digest:認證方式;

realm:領域,領域參數是強制的,在所有的盤問中都必須有,它的目的是鑒別SIP消息中的機密,在SIP實際應用中,它通常設置為SIP代理服務器所負責的域名;

qop:保護的質量,這個參數規定服務器支持哪種保護方案,客戶端可以從列表中選擇一個。值 “auth”表示只進行身份查驗, “auth-int”表示進行查驗外,還有一些完整性保護。需要看更詳細的描述,請參閱RFC2617;

nonce:為一串隨機值,在下面的請求中會一直使用到,當過了存活期后服務端將刷新生成一個新的nonce值;

opaque:一個不透明的(不讓外人知道其意義)數據字符串,在盤問中發送給用戶。

 

1.8. 3.客戶端請求  (用戶名 "Mufasa", 密碼 "Circle Of Life")

客戶端接受到請求返回后,進行HASH運算,返回Authorization參數

其中:realm,nonce,qop由服務器產生;

uri:客戶端想要訪問的URI;

nc“現時”計數器,這是一個16進制的數值,即客戶端發送出請求的數量(包括當前這個請求),這些請求都使用了當前請求中這個“現時”值。例如,對一個給定的“現時”值,在響應的第一個請求中,客戶端將發送“nc=00000001”。這個指示值的目的,是讓服務器保持這個計數器的一個副本,以便檢測重復的請求。如果這個相同的值看到了兩次,則這個請求是重復的;

cnonce:這是一個不透明的字符串值,由客戶端提供,並且客戶端和服務器都會使用,以避免用明文文本。這使得雙方都可以查驗對方的身份,並對消息的完整性提供一些保護;

response:這是由用戶代理軟件計算出的一個字符串,以證明用戶知道口令

 

HTTP AUTH 那些事 - 王紹全的博客 - 博客頻道 - CSDN.NET.html

WebApi接口安全認證——HTTP之摘要認證 - 盡善而為 - ITeye技術網站.html

詳解HTTP中的摘要認證機制 - tenfyguo的技術專欄 - 博客頻道 - CSDN.NET.html

 

作者:: 綽號:老哇的爪子claw of Eagle 偶像破壞者Iconoclast image-smasher

捕鳥王"Bird Catcher 王中之王King of Kings 虔誠者Pious 宗教信仰捍衛者 Defender Of the Faith. 卡拉卡拉紅斗篷 Caracalla red cloak

簡稱:: Emir Attilax Akbar 埃米爾 阿提拉克斯 阿克巴

全名::Emir Attilax Akbar bin Mahmud bin  attila bin Solomon bin adam Al Rapanui 埃米爾 阿提拉克斯 阿克巴 馬哈茂德  阿提拉 所羅門 本亞當  阿爾 拉帕努伊

常用名:艾提拉(艾龍),  EMAIL:1466519819@qq.com

 

 

頭銜:uke總部o2o負責人,全球網格化項目創始人,

uke宗教與文化融合事務部部長, uke宗教改革委員會副主席

Uke部落首席大酋長,

uke制度與重大會議委員會委員長,uke保安部首席大隊長,uke制度檢查委員會副會長,

奶牛科技cto ,uke 首席cto

uke波利尼西亞區大區連鎖負責人,克爾格倫群島區連鎖負責人,萊恩群島區連鎖負責人,uke湯加王國區域負責人。布維島和南喬治亞和南桑威奇群島大區連鎖負責人

 Uke軟件標准化協會理事長理事長 uke終身教育學校副校長

Uke 數據庫與存儲標准化協會副會長 uke出版社編輯總編

Uke醫院方面的創始人

 

轉載請注明來源:attilax的專欄  ?http://www.cnblogs.com/attilax/

--Atiend

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM