登錄協議

Question

我應該如何設計一個登錄協議，以更安全的方式，我有它現在是

1. 客戶端連接，併發送自己的用戶名
   
2. 服務器發送鹽（總是相同）用戶
   
3. 客戶加鹽的密碼哈希值，並將其發送到服務器
   

這樣的密碼是隱藏所有日但它並不能阻止黑客在他收到密碼後將其複製併發送出去，然後在收到密碼後發送它...

Answer 1

將安全保留到更高級別的協議（SSH，SSL）並保持簡單。

Answer 2

如果服務器只接受最初挑戰的連接上的sal密碼用這種鹽，那麼黑客必須保持連接，直到他得到與他看到的哈希相同的鹽。我並不是說這是理想的（並且Diffie-Hellman密鑰交換，然後是完全加密的身份驗證可能更安全，但是除非您小心，否則仍然容易受到中間人攻擊），但我認爲簡單的調整至少是有益的。

再說一遍，我不是安全專家，你可以說不應該接受任何非專家的安全建議。

Answer 3

第2步似乎是更大的弱點，那裏。如果你可以確保服務器發送一個「足夠大」的鹽並且永遠不會使用相同的鹽，那麼兩次（我懷疑有一小部分體面的隨機數，加上一個遞增的計數器，然後哈希就足夠了，但我不能證明它是），那可能就夠了。或者，按照ssg的要求，在SSL會話中封裝整個事情。

Answer 4

安全性很差。

不要推出自己的登錄協議，要麼使用existing proven one，要麼在加密的（SSH，SSL ...）連接上做一些簡單而強大的工作。這裏有很多強大的實踐證明的協議，以及由於輪子重新發明而導致系統失敗的很多例子 - 如果登錄保護的是任何重要的東西，根本沒有任何藉口。這就是說，如果你的目的是要學會設計這樣的算法，我強烈推薦Bruce Schneier的「Applied Cryptography」。