Http協議(5)—HTTP摘要認證

一、摘要認證的改進
        1.用摘要保護密碼
            客戶端不發送密碼,而是發送一個摘要,服務端只需驗證這個摘要是否和密碼相匹配
        
        2.單向摘要
            a.摘要是一種單向函數,將無限的輸入值轉化爲有限的
            b.常見的摘要爲MD5:
                將任意長度的字節序列轉換爲一個128位的摘要;
                MD5的128位摘要通常會被寫成32個十六進制的字符,每個字符4位

        3.用隨機數防止重放攻擊
            a.黑客可以截獲摘要對服務器無限制的重發攻擊
            b.可以將隨機數添加到密碼中,然後再根據具有隨機數的密碼生成摘要,這樣每次生成的
            摘要都不相同,可以防止重放攻擊
    
        4.摘要認證的握手機制      
            (1).服務器計算出一個隨機數
            (2).服務器將此隨機數放在www-Authenticate中,隨算法列表一起發往客戶端
            (3).客戶端選擇一個算法,計算出密碼和其他數據摘要
            (4).客戶端將摘要放在一條Authorization響應中發往服務端
            (5).服務器根據客戶端發送的響應計算出相同的摘要,然後服務器將本地生成的摘要與網絡
                 傳送過來的摘要進行比較,驗證是否匹配

二、摘要計算
        1.摘要算法的輸入數據
            a.由單向散列函數H(d)和摘要KD(s,d)組成的一對函數,s爲密碼,d爲數據
            b.一個包含安全信息的數據塊,稱爲A1
            c.一個包含請求報文中非保密屬性的數據塊,成爲A2
        
        2.算法H(d)和KD(s,d)
            H(<data>) = MD5(<data>)    
            KD(<secret>,<data>) = H(concatenate<secret>:<data>)

        3.與安全相關的數據(A1)
            密碼和受保護信息的產物,包含用戶名、密碼、保護域、隨機數
            MD5
                    爲每條請求運行單向散列函數,A1是由冒號連接起來的用戶名、域、密碼
            MD5-sess
                    只在第一次www-Authenticate握手時運行一次散列函數
            算法對A1的定義
                   
            ps:nonce爲當前隨機數;cnonce爲客戶端隨機數            

        4.與報文有關的數據(A2)
            包括URL、請求方法、報文實體,有助於防止方法、資源或報文被篡改
            根據保護質量(qop),爲A2提供兩種策略:
                    a.只包含HTTP請求方法和URL,默認
                    b.添加報文實體,當qop="auth-init"時使用
            算法對A2的定義
                    
            ps:request-method爲請求方法;uri-directive-value爲請求URI

        5.摘要認證會話
            客戶端響應對保護空間的WWW-Authenticate質詢時,會啓動一個此保護空間的認證對話

        6.預授權
            摘要認證:
                    a.服務器預先在Authentication-Info首部中發送下一個隨機數
                    b.服務器允許在一小段時間內使用同一個隨機數
                    c.客戶端和服務器使用同步的、可預測的隨機數生成算法

        7.隨機數的選擇
            BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))
                time-stamp:服務器產生的時間戳
                ETag:與所請求實體有關的ETag首部
                private-key:只有服務器知道的數據
    
        8.對稱認證
            客戶端對服務器的認證

三、增強保護質量(報文完整性檢查)
        在三種摘要首部中提供qop字段:
            WWW-Authenticate
            Authorization
            Authentication-Info

        1.報文完整性保護(qop="auth-init")

四、應該考慮的實際問題
        1.多重質詢
            服務器可以對某個資源發起多重質詢,即既提供基本認證,又提供摘要認證
        2.差錯處理
            認證服務器一定要確保URI指令指定的資源與請求行中指定的資源相同,否則返回400  BadRequest錯誤
            
        3.保護空間
            .域值與被訪問服務器的標準根URL結合在一起定義了保護空間
            .保護空間確定了可以自動應用證書的區域
            .在基本認證中,客戶端會假設請求URI中或其下的所有路徑都與當前的質詢處處於同
            一個保護空間
            .在摘要認證中,質詢的WWW-Authenticate:domain字段對保護空間做了更精確的定義

        4.重寫URI
            代理可以改變URI語法而不改變實際指向的資源來重寫URI
            由於摘要認證需要檢查URI的完整性, 故URI一經修改會破壞摘要
        
        5.緩存
            共享緩存收到Authorization首部的請求並且轉接那條請求產生的響應時,當響應中提供了
            Cache-Control:must-revalidate和Cache-Control:public時纔會將此響應作爲任何其他    
            請求的應答使用    
            Cache-Control:must-revalidate:
                    緩存可以在應答後續請求時使用響應的實體部分,但是後續請求應該和原始服務器進行
                    驗證
            Cache-Control:public:
                    對任意後繼請求都可以使用響應實體

五、安全性考慮
        1.首部篡改
            防篡改機制:
                端到端加密與首部進行數字加密

        2.重放攻擊
    
        3.多重認證機制

        4.詞典攻擊
            密碼猜測估計

        5.惡意代理攻擊和中間人攻擊
        
        6.選擇明文攻擊
            預先計算的詞典攻擊
            批量暴力型攻擊

        7.存儲密碼
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章