在登錄過程中應使用隨機數？

Question

Wikipedia提出了基於隨機數的認證的下面的例子：

1. 客戶端從服務器請求隨機數。

2. 服務器響應隨機數（即，以下稱爲「服務器 隨機數」）。

3. 客戶端使用服務器隨機數，其自己的客戶端隨機數和用戶輸入的 密碼生成哈希。

4. 客戶端將用戶輸入的用戶名，客戶端隨機數和哈希值發送到服務器 。

5. 服務器從其 數據庫檢索服務器隨機數和用戶密碼，大概是通過用戶名。

6. 服務器將服務器隨機數，客戶端隨機數和密碼合併爲 生成哈希。

7. 服務器比較剛剛生成的哈希和客戶端發送的哈希。

8. 如果哈希值匹配，則客戶端通過身份驗證。如果不是，則拒絕客戶端 。

這是否意味着服務器以純文本存儲用戶密碼？嚴重違反安全原則，建議保存密碼的醃製散列而不是實際的密碼本身？

Answer 1

該協議基本上是challenge–response authentication。它用於避免發送實際的祕密（例如密碼），但是響應只有在知道祕密的情況下才有效。爲了避免回覆攻擊，合併了一個隨機數。然而，所提及的協議要求服務器以可檢索的形式（例如，明文或加密的）存儲祕密。

但是你可以更改協議，以允許使用密碼通過要求客戶端生成相同的密碼哈希散列明文密碼，而不是：

1. 客戶端請求鹽和現時的用戶輸入用戶名來自服務器。
2. 服務器從它的數據庫中檢索鹽，通過用戶名推測，並用鹽和隨機數（即，下文中被稱爲服務器隨機數）進行響應。
3. 客戶端使用鹽和用戶輸入的密碼以產生密碼哈希並使用密碼哈希，所述服務器隨機數，和它自己的客戶端隨機數以產生隨機數散列 。
4. 客戶機發送用戶輸入的用戶名，客戶端隨機數，和隨機數散列到服務器。
5. 服務器通過用戶名從數據庫中檢索既服務器隨機數和用戶密碼哈希，大概。
6. 服務器結合服務器隨機數，客戶端隨機數和密碼哈希生成一個隨機數哈希。
7. 服務器比較隨機數散列剛剛生成隨機數散列從客戶端發送。
8. 如果哈希值匹配，則客戶端通過身份驗證。否則，客戶端被拒絕。