2011-02-02 131 views
0

考慮以下交互:是否可以驗證密碼哈希與另一個密碼哈希?

用戶將他們的用戶名和密碼存儲在Web服務器上。爲了安全起見,服務器記錄密碼的散列和一些獨特的鹽。

當用戶使用客戶端應用程序時,它會向服務器發送一個請求,提交他們的用戶名和密碼以及其他一些獨特鹽的散列。

所以,你必須在服務器上的以下信息,並且需要知道該請求是否是地道:

  • 服務器的鹽
  • 服務器的哈希密碼
  • 客戶的鹽
  • 客戶端的散列密碼

再次...客戶端發送:clientSalt + MD5(clientSalt + password)。服務器有serverSalt + MD5(serverSalt + password)。我不想知道密碼,我只想知道是否從密碼計算了相同的密碼。

不知道被哈希的密碼,有什麼辦法來驗證這兩個哈希是相同的密碼?

我的目標是在客戶端 - 服務器環境中允許某種形式的安全身份驗證,而無需通過線路交換實際密碼。這只是我的一個想法,但我甚至不知道是否有可能。

回答

4

這將需要解鎖密碼,這是不可能的。如果服務器收到:salt, md5sum,則無法看到進入md5sum的內容。

一個質詢 - 響應協議可以替代。服務器應該生成一個隨機值nonce並將其發送給客戶端。客戶端計算出md5(md5(password) | nonce))並將其返回給服務器。服務器通過檢查md5(storedpassword | nonce)進行驗證。

+0

請您詳細介紹一下嗎? – EAMann 2011-02-02 16:09:58

0

我的目標是在客戶端 - 服務器環境中允許某種形式的安全身份驗證,而無需通過線路交換實際密碼。這只是我的一個想法,但我甚至不知道是否有可能。

對於這一點,我建議尋找到的Kerberos:Official SiteWikipedia

1

不,你不能做到這一點。

一旦將鹽加入混合中,實際上不可能比較散列。 (這樣做需要在比較「未散列」數據之前對這些散列進行「散列」)。

0

這是不可能的。如果您不在服務器上存儲密碼,則用戶必須提供密碼。

OR

如果存儲在服務器上的密碼,用戶可以提供使用要求的鹽來計算哈希值。

0

您將無法使用此設置驗證散列。 如果你不想讓別人看到密碼,那麼SSL是更簡單的方法。 如果您不想使用SSL,則可以檢出SRP。 另外:不要使用MD5 + Salt來存儲你的密碼,使用密鑰加強功能,如bcrypt或scrypt。

1

Challenge-response authentication可能是要走的路,可能使用Kerberos,這取決於您的權衡。其中一個折衷是攻擊者控制客戶端使用受到攻擊的哈希來驗證自己的可能性。

不要發明自己的密碼協議。使用一個衆所周知且經過充分測試的方法。如果可能的話,使用現有的(vetted)實現。