最近調研了kerberos。看了網上學多關於kerberos的文章，我認為這篇文章比較好。
這篇文章對麻省理工的**進行翻譯。該**以四幕話劇的形式緩緩道來，有點像《研究之美》，通過兩個人的頭腦風暴講解kerberos的原理。
一、使用kerberos進行驗證的原因
1. 可靠 hadoop 本身並沒有認證功能和建立使用者組功能，使用依靠外圍的認證系統 高效
2. kerberos使用對稱鑰匙操作，比ssl的公共金鑰快 操作簡單
3. 使用者可以方便進行操作，不需要很複雜的指令。比如廢除乙個使用者只需要從kerbores的kdc資料庫中刪除即可。
二、kerberos能解決的hadoop安全認證的問題
2.1伺服器到伺服器的認證
1.沒有datanode，tasktracker的認證：
使用者可以偽裝成datanode，tasktracker，去接受jobtracker，namenode指派的任務
2.2 客戶端到伺服器的認證
1.namenode,jobtracker上沒有使用者認證：
使用者可以偽裝成其他使用者入侵到乙個hdfs 或者mapreduce集群上。
2.datanode上沒有認證：
datanode對讀入輸出並沒有認證。導致如果一些客戶端如果知道block的id，就可以任意的訪問datanode上block的資料
3.jobtracker上沒有認證：
可以任意的殺死或更改使用者的jobs，可以更改jobtracker的工作狀態
三、kerberos工作原理
3.1麻省理工kerberos**
這裡對**中的對話進行簡要概括。
a：我有個主意，我們設計乙個工作站系統，把系統軟體發在不同伺服器上，工作站通過網路練到伺服器，訪問上面的系統軟體。上述對話是對kerberos v4的執行方式介紹，kerberos v5對其有了一些改進。b：我有個問題，比如我找出你的使用者名稱，在你的檔案伺服器刪除你的檔案搞破壞怎麼辦？
a：提供服務的機器必須能夠確認請求服務的人的身份。我必須讓伺服器知道我就是我聲稱的那個人。我可以通過輸入口令的辦法證明我自己。
b：這個辦法有點笨。如果有一千個使用者，那麼每台伺服器就要知道一千個口令，如果使用者想改口令，也要通知每乙個伺服器。
a：可以這麼做。每個使用者有自己的口令，每個服務也有自己的口令。有乙個認證服務擁有所有使用者和服務的口令，將它們儲存在乙個**資料庫中。
比如說使用者想訪問郵件服務，使用者給認證服務自己的密碼，認證服務就把郵件服務的密碼給使用者，使用者就可以訪問郵件服務了。但這裡有乙個問題，認證服務不能把郵件服務的密碼直接給使用者，那麼使用者下次就可以直接用密碼訪問了，繞過了認證服務，我就可以冒充別人用密碼訪問服務。認證服務給使用者一張」票「，票裡包含著使用者名稱，使用者名稱是用郵件服務的密碼加密的。郵件服務拿自己的密碼解密，用得到的使用者名稱對比提供的使用者名稱。如果相符則通過認證。
b：有個問題，服務如何知道正確解密了「票」。也許應該把服務的名字也加入票裡。
a：就像這樣？
票 —｛使用者名稱：服務名｝
a：像這樣？
b：聽起來我每次訪問郵件服務都要請求一次郵件的「票」嗎？
a：我認為你只需要得到一次郵件服務的「票」就可以，再此使用傳乙份拷貝的票就可以了。
b：我仍有問題，我在每次使用沒有「票」的服務時，是不是都要傳一次我的密碼。這就是說你在網路上明文使用你的密碼，如果我抓包抓到了你的密碼，我就可以使用你的名字來使用任何服務。
a：好吧，我們先明確一下需求：一、使用者只需要輸入一次口令；二、口令不能以明文形式傳輸。對於要求一，創造乙個「票據授予」服務，使用者向認證服務認明身份後，「票據授予」把認證服務的票給使用者，通過票而不是口令進行認證服務。我只需獲得票據授予票一次就可以。
b：如何在獲取票據授予票時不用明文傳輸口令？
a：使用者通過乙個kinit程式進行票據授予服務，進行票據授予時，kinit不是將使用者口令傳給認證伺服器，而是將使用者名稱傳給認證伺服器。認證伺服器通過使用者名稱對應的口令對「票據授予」票進行加密傳給使用者，使用者在用自己的口令進行解密。
b：我感覺服務票是可重用的這一點很危險。比如我使用了乙個不安全的工作站獲取服務，當我離開時，無意中留下了一些票。別人登陸這個工作站發現我留下來的這些票後，就可以對我的檔案進行破壞，還可以把票拷走，永遠使用。
a：可以設計一些程式在使用者離開時銷毀這些票
a：我們可以給每張票乙個有效期。
b：像這樣？
a：那票的有效期就定為8小時吧。但有乙個問題如果我只用了2小時就離開，那麼其他人可以用拷貝來的票使用6小時，這段時間足夠做很多事了。
b：這確實是個問題。
a：如果我們可以設計一種無法重用的票就好了。
但這是乙個笨辦法。重述一遍我們**的問題。我們希望網路服務必須能夠證明使用票的人就是票上所記的人。我們先重新整理下思路。
現在客戶端發給伺服器三樣東西：
使用者名稱
網路位址
適當的服務票據。
現在有三個認證過程：
服務能否解密票據
票過期了嗎
票中的名字和工作站位址與使用者提供的匹配嗎
第三點有點問題，壞人可以串改他的使用者名稱和密碼。而服務無法判斷。而服務之所以無法判斷是因為沒有和使用者共享乙個秘密。為什麼不讓認證服務為合法使用者和服務之間設乙個口令呢？比如發乙份會話金鑰。服務可以用金鑰驗證使用者身份。
b：認證服務如何給雙方發金鑰呢？
a：使用者從認證服務獲得會話密碼。
認證服務的回應－［會話密碼｜票］
服務從票裡獲得會話密碼，就像這樣：
當使用者請求服務時，客戶端生成乙個「驗證器」，「驗證器」。用使用者名稱和位址用會話金鑰加密。
驗證器－｛使用者名稱：位址｝ 會話金鑰加密
伺服器解開票後獲得會話金鑰，再用會話金鑰解密驗證器獲得使用者名稱和位址。
b：如果我把驗證器和票一起偷走，不也是還可以做壞事嗎？等等，我們可以把驗證器設計成只可以使用一次。把有效期和時間戳放在上面。假設每個驗證有兩分鐘的有效期。但有乙個潛在的問題，我拷貝了乙份認證服務對你請求票據時的回應。那裡面有會話金鑰和票，我也可以根據會話金鑰生成驗證器。
a：我也想到了這點，但我認為這是不可能的。我們可以這麼做。在票據授予服務時，返回的會話金鑰和票據授予票用使用者密碼加密，普通服務返回的票用票據授予會話金鑰加密。
b：我又想到了乙個嚴重的問題。上面的認證方式只能防止錯誤的使用者使用伺服器，不能防止錯誤的伺服器被傳送服務請求，也就是說如果我偽造了乙個伺服器我就可以得到你的請求。這顯然是不安全的。我們還需要為客戶端提供一種驗證伺服器的方法。服務端可以向客戶端發回應答，應答用會話金鑰加密，服務端需要用自己的口令去解密票據才可以得到會話金鑰。這樣系統就堅實了。
a：我們把這個認證服務叫做kerberos吧。
第一處改變是因為意識到驗證器用少於五分鐘的有效期不足以防止攻擊者進行重演，如果攻擊者是用乙個程式自動的擷取票和驗證器並進行重演的話。在kerberos v5中，驗證器真正的只能用一次因為伺服器用『重演緩衝區』儲存了最近一次提交的驗證器的資訊。如果攻擊者試圖擷取驗證器並重用它，『重演緩衝區』會發現驗證器已經被提交了。
第二個主要改變是kerberos送給kinit服務票的時候，票不再是用使用者的口令加密。它已經用票據授予服務的口令加過密了。票據授予服務的票被用來獲取其它票的時候，它直接就被傳輸了。因此票不需要再用使用者的口令加密一次。乙個類似的改變也應用到票據授權服務協議;從票據授權服務返回的票也不再用票據授權服務的口令來加密了，因為它所包含的票已經被對應的服務的口令加過密了。
3.2 基本概念
從上文四幕話劇的介紹我們可以引申出幾個基本概念
3.3工作流程
我們來先整理一下kerberos的工作流程
1.客戶端許可證服務
1）首先princal傳送自己的使用者名稱等資訊給kdc請求許可證服務
2）kdc呼叫tgs，得到乙個tgt（許可票據票）裡面包含使用者名稱，位址，session 密碼 ，有效期，時間戳等，tgt用許可證服務密碼加密和乙個session 密碼用使用者密碼加密。傳送給princal
3） princal用自己的密碼解謎獲得session 密碼 和加密後的tgt
2.客戶端獲取服務的認證票
1）princal將自己的使用者名稱，位址，請求的服務，時間戳等用tgs的session 密碼 加密得到乙個驗證器，和tgt一起傳送給kdc
2）kdc判斷驗證器是否過期（只能被使用一次），再用自己的密碼解密tgt獲得使用者的資訊和session密碼，再用session密碼解密驗證器，比對使用者資訊。生成乙個目標server的session密碼，用這個session密碼和使用者資訊組成乙個server票，再用kdc儲存的這個 server的密碼對票進行加密。用使用者密碼對server的session密碼進行加密。一併返回給princal。
3.客戶端與目標server的相互認證
1）princal收到kdc的返回包後，用自己的密碼解密session 密碼加密檔案得到session 密碼。將自己的使用者名稱，位址，請求的服務，時間戳等用session 密碼加密得到乙個驗證器。將驗證器和票一起發給目標服務的伺服器
2）目標伺服器判斷驗證器是否過期（只能被使用一次），再用自己的密碼解密票據獲得使用者的資訊和session 密碼，再用session密碼解密驗證器，比對使用者資訊。創造乙個應答，用解密出來的session密碼加密，回答給princal
3）princal接到回答後用session密碼解密，如果解密成功，就開始與服務傳送命令。
kerberos工作原理
最近調研了kerberos。看了網上學多關於kerberos的文章，我認為這篇文章比較好。這篇文章對麻省理工的 進行翻譯。該 以四幕話劇的形式緩緩道來，有點像 研究之美 通過兩個人的頭腦風暴講解kerberos的原理。一 使用kerberos進行驗證的原因 1.可靠 hadoop 本身並沒有認證功能...
Kerberos原理解析
kerberos這一名詞 於希臘神話 三個頭的狗 地獄之門守護者 系統設計上採用客戶端 伺服器結構與des加密技術，並且能夠進行相互認證，即客戶端和伺服器端均可對對方進行身份認證。可以用於防止竊聽 防止replay攻擊 保護資料完整性等場合，是一種應用對稱金鑰體制進行金鑰管理的系統。支援sso si...
kerberos原理及流程
概念 kerberos是一種網路認證協議，其設計目標是通過金鑰系統為客戶機 伺服器應用程式提供強大的認證服務。該認證過程的實現不依賴於主機作業系統的認證，無需基於主機位址的信任，不要求網路上所有主機的物理安全，並假定網路上傳送的資料報可以被任意地讀取 修改和插入資料。在以上情況下，kerberos作...