Java和Kerberos

我想比較一個字符串與當前通過身份驗證的用戶的密碼（加密密鑰比較）。這似乎是從票據緩存中檢索密碼，但我怎麼能做到這一點？Java和Kerberos

謝謝

2010-09-28 BigMac

我不知道這是否有可能。這個散列可能會被一個只有服務器知道的密鑰淹沒。我想嘗試的是使用用戶的ID和給定的字符串進行身份驗證。如果服務器接受認證請求，則密碼有效。

2010-09-28 12:29:00 Barend

謝謝你的回答。我無法應用您的解決方案，因爲用戶已經通過身份驗證。爲了讓他改變他的kerberos密碼，我必須檢查他的身份，購買他的舊密碼。然後我必須將輸入與真實密碼進行比較。 – BigMac 2010-09-28 14:43:10

無法從客戶端或kerberos系統中任何位置的可用信息中檢索密碼。按照kerberos article in wikipedia（持有類似的信息什麼，我在其他來源讀取），用戶輸入的密碼進行散列用單向函數到的東西，作爲從在這一點上的祕密。密鑰在密鑰分發中心（KDC）可用，票證授予票據（TGT）以此祕密對稱加密。爲了接收和使用TGT，客戶必須提供解密包的祕密 - 這是通過向用戶索要密碼來完成的。這樣做後，TGT被解密並保存在票據緩存中。

的TGT本身有一個祕密只有KDC知道的加密部分，它不保存用戶的密碼。例如，如this article from 2000所解釋的那樣，密碼不存儲在票據緩存中 - 只是來自TGT的部分。根據我的理解，使用票據緩存檢查用戶密碼是不可能的。

您可能需要編寫自己的CallbackHandler以某種方式重新使用或編程提供憑據，但是從我的理解，這可能導致安全問題。

你可能要考慮總不同的方法解決你的問題，但目前還很少信息表明其他任何解決方案。

來源

2010-10-06 20:14:11 MaoPU

謝謝毛浦這個偉大的答案。實際上，從Kerberos數據庫檢索用戶密碼是不可能的。爲了避免安全漏洞，我寧願調用一個執行密碼檢查和更改的shell腳本。 – BigMac 2010-10-07 13:39:10

這是正確的。密碼信息對於KDC是私人的，並且在運行時不能從KDC之外以編程方式檢索。否則這將是一個巨大的安全漏洞。 – 2010-11-23 20:36:39

回答

相關問題