【文章內(nèi)容簡介】 ??????簽名了一個信息 ?，如果 Alice 發(fā)送 13 信息 ?和簽名 ??給 Bob，然后 Bob 用 Alice 的公鑰通過 ? = *??+????????對簽名進行驗證。然而，若信息 ?的長度非常大， ,?????????的計算開銷比較大。 假如 Alice 使用哈希函數(shù) (?)，不對文件 ?本身進行而對文件 ?的哈希 (?)進行簽名，簽 名 (?)比文件 ?本身小得多，如果 ?′ 與 ?有 1 bit的不同，那么簽名 .?′ /和 (?)會相差非常大，平均會有一半的不同。已知函數(shù) ，Alice 能通過計算 ?? = , (?)????????簽名信息 ?，發(fā)送給 Bob 信息 ?和簽名 ??，然后， Bob 通過 (?) = *??+????????進行驗證。 對 消 息 M 進 行哈 希 h ( M )對 哈 希 h ( M )進 行 簽 名S [ h ( M ) ]對 簽 名 S [ h ( M ) ]進 行 驗 證消 息M簽 名 S [ h ( M ) ]密 碼 生 成 器私 鑰公 鑰消 息M圖 數(shù)字簽名過程 對 (?)簽名而不是直接對 ?進行簽名有什么好處呢？假定 (?)的計算是高效的，對哈希 (?)用私鑰進行簽名比對整個 ?本身簽名要高效得多，因為Alice 只需發(fā)送更少的附加內(nèi)容給 Bob，這樣也更節(jié)省空間和帶寬。 哈希函數(shù)也有兩種類型，密碼哈希函數(shù) (Cryptographic Hash Function)和非密碼哈希函數(shù) (Noncryptographic Hash Function)。 一些使用哈希函數(shù)的標準的應(yīng)用包括認證（ Authentication），消息完整性驗證（ Message Integrity）（一般用的是 HMAC），消息指紋（ Message fingerprint），臟數(shù)據(jù)檢測（ Data Corruption Detection），和高效的數(shù)字簽名。 認證 認證簡介 訪問控制主要分為認證（ Authentication）和授權(quán)（ Authorization）兩個方面。 14 “認證（ Authentication）又可稱作鑒別，它主要用來對用戶的身份或者報文來源及內(nèi)容進行驗證和識別，以確保信息的真實性與完整性?！? 認證技術(shù)的共同特性是對一些參數(shù)是否有效進行驗證，檢查參數(shù)是否能滿足預(yù)期的關(guān)系，密碼學通常可以認證技術(shù)提供一種較為好的安全認證，就目前來說，密碼學是大部分認證方法的基礎(chǔ)。 認證處理的問題是，是否用 戶（或者其他實體）能夠訪問以一些特定的系統(tǒng)或者資源。認證引起了許多相關(guān)的協(xié)議的出現(xiàn)，尤其當認證發(fā)生在網(wǎng)絡(luò)上時，網(wǎng)絡(luò)也是一個大部分機器與機器相互認證的環(huán)境。 按照定義，認證過的用戶能夠訪問一些系統(tǒng)資源，但是認證過的用戶也不能訪問所有的資源，比如，也許我們僅僅能夠允許一個合法的用戶，像管理員，在系統(tǒng)上安裝軟件。盡管認證是一個判斷過程 —— 訪問授權(quán)了還是沒有授權(quán)，我們還是要限制認證過用戶的一些行為，這就是認證領(lǐng)域要做的事。 訪問控制經(jīng)常作為認證的同義詞，但是訪問控制有它更廣泛的定義，認證只是訪問控制的一種，訪問控制可以分為兩個方面： 1) 認證：誰能干什么？ 2) 授權(quán)：你被允許做這件事嗎？ 認證的方法： 認證通常基于下面幾種情況的結(jié)合： 1) 你知道的一些東西 2) 你擁有的一些東西 3) 你是什么 密碼認證是“你知道的一些東西”的例子，現(xiàn)在業(yè)界已經(jīng)普遍接受這個觀點，密碼是整個安全系統(tǒng)最薄弱的環(huán)節(jié)。 銀行卡或者智能卡的認證方式是“你擁有的一些東西”的實例。 而像手紋，虹膜等基于生物特征的認證方式則是“你是什么”的認證方式。 密碼認證 一個比較理想的密碼是一個只有你知道的，能夠被系統(tǒng)驗證的，并且別人無法猜測的密碼。然而，在現(xiàn)實中我們很難達到這個理想的標準。 15 毫無疑問，你熟悉自己的密碼。在當今，如果沒有這些大量密碼，去安全地使用計算機幾乎是不可能。一個重要的事實是，其他東西充當著我們的密碼，當我們忘記登錄密碼時，就算你忘記了自己的密碼，一個做得比較友好的網(wǎng)站就會基于你的社會身份來認證你，比如，網(wǎng)站會讓你回答一些問題，“你媽媽的名字叫什么？”，“你的生日是哪一天？”，“你在哪里上得小學”??通過正確回答這些問題來認證你，然而，很顯然的是，這些 信息并不是只有你知道。 而且，當用戶選擇自己的密碼時，為了方便記憶，會選擇一些“不好”的密碼，比如，我們在網(wǎng)站注冊時，就很有可能用我們的手機號碼或者出生日期或者姓名信息作為我們的登錄密碼，這些密碼很容易就被破解。事實上，通過數(shù)學方面的論證，用這種密碼在本質(zhì)上是不安全的。 一個解決方案是，生成隨機值代替密碼，密碼攻擊者若要暴力破解這個隨機值密碼，就會疲于搜索。這種解決方案的問題是人們必須要自己能記住這個隨機密碼。 但是我們還是一直在使用密碼認證的方式，我們首先要理解為什么密碼認證的方式這么流行，即，為什么“ 我所知道的一些東西”比“比我擁有的一些東西”和“我是什么”更加流行，什么時候后兩種情況更加安全？答案可能主要是成本因素，其次是便捷方面的考慮。密碼是免費的，智能卡和生物識別設(shè)備是要花錢的。同樣，對于一個工作負重的系統(tǒng)管理員來說，分發(fā)一個密碼比發(fā)放智能卡要更方便。 現(xiàn)在來看一下為什么隨機值比為了方便記憶有意義的密碼值更容易破解，假如我是一個密碼破解者，若加密算法本身是安全的，當面對一個 64位長度的隨機密碼，這有 264中可能性，要期望找到正確的密碼，平均我需要嘗試 263種可能的值。假如我面對一個 8位長度的字符密 碼，每一個字符有 256中可能，總共就有 2568 = 264種可能，這與 64位的二進制長度一樣難以破解。 然而，用戶并不喜歡選擇隨機密碼，主要的原因是，用戶必須記住這些密碼，結(jié)果，用戶更有可能選擇這樣一個 8 位長度的密碼 Passw rd 而不是 e?!dkamp。?? 16 結(jié)果，一個聰明的密碼破解者就只需做遠遠少于 263種猜測成功地找到正確的密碼。例如，一本字典的詞匯量大概只有 1 000 000 ≈ 220，破解者只需在 262里一個子集去找尋，成功的概率提高了 264220 = 244 ≈ 17 000 000 000 000倍。非隨 機密碼在根本上存有嚴重的安全性問題。 授權(quán) 授權(quán)是訪問控制的一部分，主要處理的問題是，限制認證了的用戶的行為，技術(shù)上，授權(quán)是訪問控制的一個方面，認證 則 是另外一個方面 。 傳統(tǒng)上，授權(quán)處理這樣一種情景，假如我們已經(jīng)鑒別（或認證）了某一個用戶，比如 Alice 的身份，我們想限制她的在只被允許的活動上。盡管認證是一個二分選擇 —— 是合法用戶或者不是，而授權(quán)則沒有這么簡單。 Oauth 協(xié)議 Oauth 協(xié)議是一個安全的，開放的，免費并且簡易的授權(quán)標準， Oauth 為客戶端提供了一種以資源的擁有者去訪問服務(wù)器資源的方案，也提供給終端客戶在不共享證書的情況下，授權(quán)第三方去訪問他服務(wù)器資源的流程。 跟以前的授權(quán)方式不同的地方是， Oauth 授權(quán)不會使得第三方觸及用戶的賬戶信息，比如用戶名和密碼，也就是說第三方在無需使用用戶的用戶名和密碼就能夠申請獲取用戶資源的授權(quán)，因為這個特點， Oauth 被認為是安全的。 任何第三方都可以使用 Oauth 的認證服務(wù)，服務(wù)提供商也能夠?qū)崿F(xiàn)自己的Oauth 認證服務(wù)，因此， Oauth 是開放的。業(yè)界已經(jīng)有了 Oauth 的各種語言的開發(fā)包，像 Java， Javascript， PHP， Ruby 等等，因此，使用 Oauth 變得簡易。 Oauth 產(chǎn)生的背景 先看一個典型的案例： 假設(shè)用戶，比如 Alice，使用了兩項網(wǎng)絡(luò)服務(wù)，第一項是圖片在線存儲服務(wù)A，第二項服務(wù)是圖片在線打印的服務(wù) B，如圖 所示，兩項服務(wù)是由兩家不同的服務(wù)提供商支持的， Alice 在兩家服務(wù)提供商的網(wǎng)站上分別 注冊了兩個不同的賬戶，擁有不同的密碼。如果 Alice 要使用 B服務(wù)在線打印存儲在服務(wù) A上的 17 圖片，她該怎么辦呢？有兩種方案可供選擇。 圖 在線儲存和在線打印的問題 方案一： Alice 首先從服務(wù)器 A 下載要打印的圖片，然后上傳到服務(wù)器 B，使用服務(wù)B在線打印。這種方案比較安全，但是也很繁瑣，效率很低。 方案二： Alice 將自己在服務(wù) A 上的賬戶和密碼告訴服務(wù) B，服務(wù) B利用這個賬戶和密碼登錄服務(wù) A，下載圖片到服務(wù)器 B并打印。這種方案非常高效，但是安全性極低，比如服務(wù)器 B可以利用 Alice 的賬戶和密碼對服務(wù) 器 A上的圖片進行篡改和刪除。 很多公司都遇到過這種問題，包括業(yè)界很有名的 Google， Microsoft和 Yahoo都嘗試提出自己的解決方案，這就促使了 Oauth項目組的誕生。 Oauth是由 Blaine Cook， Larry Halff， Chris Messina 和 David Recordon 共同發(fā)起的，目的是為API 訪問授權(quán)提供一個開放的標準。 Oauth 的相關(guān)術(shù)語 在了解 Oauth 的流程之前，我們先看看 Oauth 的一些術(shù)語的定義： 表 Oauth相關(guān)的三個 URL 術(shù)語 名詞解釋 Request Token URL 獲取未授權(quán)的 Request Token服務(wù)地址 User Authorization 獲取用戶授權(quán)的 Request Token服務(wù)地址 18 Access Token URL 用授權(quán)的 Request Token換取 Access Token的服務(wù)地址 表 Oauth相關(guān)參數(shù)的定義 術(shù)語 名詞 解釋 oauth_consumer_key 使用者 ID， Oauth服務(wù)的直接使用者是開發(fā)者開發(fā)出來的應(yīng)用，該參數(shù)值的獲取一般是要去 Oauth服務(wù)提供商出注冊一個應(yīng)用，再獲取該應(yīng)用的 oauth_consumer_key oauth_consumer_secret oauth_consumer_key對應(yīng)的密鑰 oauth_signature_memethod 請求串的簽名方法，應(yīng)用每次像 Oauth三個服務(wù)地址發(fā)送請求時，必須對請求進行簽名。簽名的方法有 HMACSHA1，PLAINTEXT和 RSASHA1等三種 oauth_signature 用上面的簽名方法對請求簽名 oauth_timestamp 發(fā)起請求的時間戳，其值是 1970 00： 00） 00GMT的秒數(shù)，必須是大于 0的整數(shù)，本次請求的時間戳必須大于或者等于上次的時間戳 oauth_nonce 隨機生成的字符串，用于防止請求的重復(fù)，防止外界的非法攻擊 oauth_version Oauth的版本號，可選，其值必須為 Oauth Http 響應(yīng)代碼 HTTP 400 Bad Request 請求錯誤 19 表 請求出錯類型 Unsupported parameter 參數(shù)錯誤 Unsupported signature method 簽名方法錯誤 Missing required parameter 參數(shù)丟失 Duplicated OAuth Protocal Parameter 參數(shù)重復(fù) HTTP 401 Unauthorized 未授權(quán) 表 HTTP 401錯誤 Invalid Consumer Key 非法 key Invalid/expired Token 失效或者非法的 token Invalid signature 簽名非法 Invalid/used nonce 非法的 nonce Oauth 認證授權(quán)流程 弄清 Oauth 的相關(guān)術(shù)語之后，我們來看一下 Oauth 的認證授權(quán)流程。 Oauth的認證授權(quán)分為三個步驟： 1. 獲取未授權(quán) Request Token； 2. 獲取用戶授權(quán)的 Request Token； 3. 用授權(quán)的 Request Token 換取 Access Token。 S e r v i c e P r o v i d e rU s e r C o n s u m e r1 .請 求 服 務(wù)6 .服 務(wù) 該 用 戶2 .請 求 訪 問 用 戶 資 源5 .獲 得 授 權(quán)3 .可 以 訪 問 你 的 資 源 嗎 ？4 . U s e r 授 權(quán) 訪 問 20 圖 Oauth授權(quán) 當應(yīng)用拿到了 Access Token 之后，就能有權(quán)地訪問用戶授權(quán)資源了。這三個步驟剛好對應(yīng) Oauth 的三個服務(wù)地址。在三個步驟中，其中的每一步驟都請求一個 URL，并收到相關(guān)的信息，然后拿著上步的信息去請求下面的 URL，一直到拿到 Access Token 為止，具體步驟如圖 ： 圖 Oauth 授權(quán)詳細流程圖 （圖片來自 Oauth 官方網(wǎng)站： 具體的執(zhí)行過程解析： 1) Consumer（ 一般是第三方應(yīng)用程序 ）向 Oauth 服務(wù) 提供商 請求未曾授權(quán)的 Request Token。向 Request URL 提出請求，請求 需要 的參數(shù)如圖 所示。 2) Oauth 服務(wù)提供商