安全的密碼傳輸通過未加密的TCP/IP

Question

我正在爲移動客戶端 - 服務器通信定製tcp/ip協議的設計階段。如果不需要（數據不敏感），我想避免使用SSL（出於交換時間原因（握手延遲和節省週期））。

我的問題是，通過未加密連接傳輸驗證信息的最佳實踐方式是什麼？我相當喜歡SRP或J-PAKE（他們生成安全的會話標記，哈希/鹽友好，並允許在必要時踢入TLS），我相信它們都是在OpenSSL中實現的。不過，我有點警惕，因爲我沒有看到許多人爲此使用這些算法。對於討論這個主題的任何材料，我一般也會很欣賞，因爲我很難找到任何材料。

編輯

也許這個問題應該是：是有通過未加密的TCP/IP安全密碼最佳實踐的方法嗎？如果不是，選擇一種特定方法的原因是什麼？ （到目前爲止，Rooks的答案在精神上最接近這個問題，即使它確實違反了這封信）。

編輯，部分德塞夫勒

我在客戶端 - 服務器的認證，其中有一個期望，雙方都有一個共享密鑰（密碼）先驗的情況感興趣。

Answer 1

你應該看看"Diffie-Hellman key exchange"：

Diffie-Hellman密鑰交換（d-H）是一種加密協議，允許有彼此的先驗知識，雙方共同建立共享密鑰關鍵在一個不安全的通信渠道。然後可以使用該密鑰來使用對稱密鑰密碼來加密隨後的通信。

交換密鑰後，您可以使用此密鑰加密密碼並通過不安全的協議傳輸密碼。

Answer 2

您可以使用質詢 - 響應算法。算法如下：

• 服務器向客戶端發送一個隨機字符串。
• 客戶端將此字符串與密碼相結合（通過組合，您可以對它們進行異或將它們追加）。
• 客戶端計算結果的散列（例如SHA1），並將其發送到服務器。
• 服務器使用此隨機數和真實密碼計算相同的散列值。
• 服務器比較這兩個散列。

由於您不應以純文本格式存儲密碼，而應以散列代替，因此客戶端應在開始時計算此散列值。

有可能有幾個庫實現這個，所以你可能不需要自己編碼。

Answer 3

我仍然認爲SSL是迄今爲止您的最佳選擇，畢竟爲什麼重新發明風車時會出現如此多的錯誤？如果您擁有「好」和「壞」（受損）證書列表，則不必購買昂貴的證書。 openSSL是完全免費的，我沒有看到不使用它的好理由。

有些事情你可能不知道：ssl handshakes can be resumed。

您也可以使用SSL/TLS over UDP來減少稱爲DTLS的開銷。