1. 程式人生 > >基於HTTP 協議認證介紹與實現

基於HTTP 協議認證介紹與實現

idt 興趣 cati 生成 保護 進行 pos 響應 label

一直對http 的頭認證有興趣,就是路由器的那種彈出對話框輸入賬號密碼怎麽實現一直不明白,最近,翻了一下http 協議,發現這是一個RFC 2617的實現,所以寫篇文章介紹一下吧.

這是一個用於web瀏覽器或其他客戶端在請求時提供用戶名和密碼的登錄認證,要實現這個認證很簡單:

我們先來看下協議裏面怎麽定義這個認證的. 1. 編碼: 將用戶名 追加一個 冒號(‘:‘)接上密碼,把得出的結果字符串在用Base64算法編碼.

  1. 請求頭: Authorization: 認證類型 編碼字符串

來看一下客戶端如何發起請求例如,有一個用戶名為:tom, 密碼為:123456 怎麽認證呢?

步驟如下 1. 編碼

Base64(‘tom:123456‘) == dG9tOjEyMzQ1Ng==;

  1. 把編碼結果放到請求頭當中

    Authorization: Basic dG9tOjEyMzQ1Ng==

請求樣例客戶端

1
2
3
GET / HTTP/1.1
Host: localhost
Authorization: Basic dG9tOjEyMzQ1Ng

服務端應答

1
2
3
4
HTTP/1.1 200 OK
Date: Thu, 13 Jun 2013 20:25:37 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 53

如果沒有認證信息

1
2
3
HTTP/1.1 401 Authorization Required
Date: Thu, 13 Jun 2013 20:25:37 GMT
WWW-Authenticate: Basic realm="Users"

驗證失敗的時候,響應頭加上WWW-Authenticate: Basic realm="請求域".

這種http 基本實現,幾乎目前所有瀏覽器都支持.不過,大家可以發現,直接把用戶名和密碼只是進行一次base64 編碼實際上是很不安全的,因為對base64進行反編碼十分容易,所以這種驗證雖然簡便,但是很少會在公開訪問的互聯網使用,一般多用在小的私有系統,例如,你們家裏頭的路由器,多用這種認證方式.

這個認證可以看做是基本認證的增強版本,使用隨機數+密碼進行md5,防止通過直接的分析密碼MD5防止破解. 摘要訪問認證最初由 RFC 2069 (HTTP的一個擴展:摘要訪問認證)中被定義加密步驟:

  1. 技術分享圖片

  2. 技術分享圖片

  3. 技術分享圖片

後來發現,就算這樣還是不安全(md5 可以用彩虹表進行攻擊),所以在RFC 2617入了一系列安全增強的選項;“保護質量”(qop)、隨機數計數器由客戶端增加、以及客戶生成的隨機數。這些增強為了防止如選擇明文攻擊的密碼分析。

技術分享圖片

  1. 如果 qop 值為“auth”或未指定,那麽 HA2 為

    技術分享圖片

  2. 如果 qop 值為“auth-int”,那麽 HA2 為

    技術分享圖片

  3. 如果 qop 值為“auth”或“auth-int”,那麽如下計算 response:

    技術分享圖片

  4. 如果 qop 未指定,那麽如下計算 response:

    技術分享圖片

好了,知道加密步驟,下面我們用文字來描述一下;

最後,我們的response 由三步計算所得. 1. 對用戶名、認證域(realm)以及密碼的合並值計算 MD5 哈希值,結果稱為 HA1。

HA1 = MD5( "tom:Hi!:123456" ) = d8ae91c6c50fabdac442ef8d6a68ae8c

  1. 對HTTP方法以及URI的摘要的合並值計算 MD5 哈希值,例如,"GET" 和 "/index.html",結果稱為 HA2。

    HA2 = MD5( "GET:/" ) = 71998c64aea37ae77020c49c00f73fa8

  2. 最後生成的響應碼

    Response = MD5("d8ae91c6c50fabdac442ef8d6a68ae8c:L4qfzASytyQJAC2B1Lvy2llPpj9R8Jd3:00000001:c2dc5b32ad69187a
    :auth:71998c64aea37ae77020c49c00f73fa8") = 2f22e6d56dabb168702b8bb2d4e72453;

RFC2617 的安全增強的主要方式:

發起請求的時候,服務器會生成一個密碼隨機數(nonce)(而這個隨機數只有每次"401"相應後才會更新),為了防止攻擊者可以簡單的使用同樣的認證信息發起老的請求,於是,在後續的請求中就有一個隨機數計數器(cnonce),而且每次請求必須必前一次使用的打.這樣,服務器每次生成新的隨機數都會記錄下來,計數器增加.在RESPONSE 碼中我們可以看出計數器的值會導致不同的值,這樣就可以拒絕掉任何錯誤的請求.

請求樣例(服務端 qop 設置為"auth")

客戶端 無認證

1
2
GET / HTTP/1.1
Host: localhost

服務器響應(qop 為 ‘auth‘)

1
2
3
HTTP/1.1 401 Authorization Required
Date: Thu, 13 Jun 2013 20:25:37 GMT
WWW-Authenticate: Digest realm="Hi!", nonce="HSfb5dy15hKejXAbZ2VXjVbgNC8sC1Gq", qop="auth"

客戶端請求(用戶名: "tom", 密碼 "123456")

1
2
3
4
5
6
7
8
9
GET / HTTP/1.1
Host: localhost
Authorization: Digest username="tom",
                     realm="Hi!",
                     nonce="L4qfzASytyQJAC2B1Lvy2llPpj9R8Jd3",
                     uri="/",
                     qop=auth,
                     nc=00000001,
                     cnonce="c2dc5b32ad69187a",                     response="2f22e6d56dabb168702b8bb2d4e72453"

服務端應答

1
2
3
4
HTTP/1.1 200 OK
Date: Thu, 13 Jun 2013 20:25:37 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 53

註意qop 設置的時候慎用:auth-int,因為一些常用瀏覽器和服務端並沒有實現這個協議.

基於HTTP 協議認證介紹與實現