您不能。

要通過不安全的通道安全地發送信息，您需要加密。

對稱加密已失效，因為您首先需要傳輸密鑰，而這是無法在不安全的通道[*]上安全進行的。

這給您留下了公共密鑰密碼學。您當然可以自己動手，但是您不想成為戴夫，所以就這樣了，這使您只能使用HTTPS。

_{[*]當然，您可以嘗試使用安全通道交換密鑰，例如，物理交換密鑰。然後，您可以使用諸如Kerberos之類的秘密密鑰加密。 sub>}

TLS確實是唯一的方法。

但是如果我使用JavaScript對其進行加密怎麼辦？

攻擊者可以更改您的JavaScript。發送給客戶端，或者簡單地註入自己的JavaScript來記錄輸入的所有信息。

然後，我將使用CSP和SRI來防止添加腳本和修改自己的腳本。

很高興您正在使用現代工具來幫助保護您的網站，但是在非安全上下文中的SRI實際上只能防止外部資源受到損害。攻擊者只需修改CSP標頭和SRI標籤即可。

從一開始就不使用加密，實際上是沒有辦法做到的，唯一的標準方法就是使用TLS。

雖然我同意您應該使用HTTPS，但是通過使用Salted Challenge Response身份驗證機制（SCRAM，請參閱 RFC 5802）進行實際的身份驗證交換，可以使其更加安全。

實現並非易事，但要點是，不是向服務器發送密碼，而是向服務器發送知道密碼的證明，而不是向服務器發送密碼。由於推導證明使用的是客戶端和服務器的隨機數，因此攻擊者無法重用它（就像發送哈希本身一樣）。

與HTTPS和您描述的基本身份驗證：

1. 服務器在登錄時從未真正看到您的密碼。如果有人設法在服務器上插入惡意代碼，他們仍然不會知道您的密碼是什麼。
2. 如果HTTPS實施中存在錯誤（請注意Heartbleed），則攻擊者仍將無法獲取您的密碼。因為，即使繞過TLS，也無法使用密碼。
3. 如果由於某種原因您無法使用HTTPS，則比直接發送密碼要好。攻擊者將無法根據交換信息猜測您的密碼。也就是說，您仍然應該使用HTTPS，因為深度防禦會更好。
ol>

請注意，這只有在客戶端能夠執行SCRAM的情況下才是安全的計算無需從服務器下載代碼。您可以提供一個胖客戶端，或者用戶可以編寫他們自己控制的代碼。通過HTTP下載SCRAM代碼將使攻擊者有機會修改SCRAM代碼，以以明文形式發送密碼，或以其他方式公開密碼。

在這種情況下，您絕對應該部署TLS。

如果您決定嘗試通過HTTP發明一種傳輸安全系統，那麼最終您最終將最終實現TLS功能的多餘部分。在設計和實現這樣的系統時，有很多陷阱需要注意，當您選擇嘗試使用不提供許多安全功能的語言來實現該系統時，這些陷阱會進一步放大。

即使您確實在JavaScript中實現了加密協議的正確實現（這已經是一個很大的挑戰），您不能依靠該實現來抵抗定時攻擊，並且如果有人禁用了腳本（例如，使用NoScript），整個過程就會中斷。

作為一般規則，您應該選擇由最簡單，易於理解且值得信賴的組件組成的實現，而這些實現要求您編寫最少數量的安全關鍵代碼。引用安德魯·坦南鮑姆（Andrew Tannenbaum）的話：

（在應用程序安全方面）的大量問題是由有缺陷的軟件引起的，這是由於供應商不斷向其添加更多功能而引起的。他們的程序，這不可避免地意味著更多的代碼，因此也意味著更多的錯誤。

我是否需要實現某種加密算法，例如RSA公鑰加密？

如果您正在考慮嘗試這樣做，則不妨全力以赴並使用HTTPS。由於您似乎不是專家，因此“滾動自己的”加密無疑會有誤操作，從而使它不安全。

實際上很有可能。

密碼必須在客戶端進行哈希處理，但不能使用靜態函數。以下方法分兩個步驟，並受到摘要訪問身份驗證的啟發：

注意：服務器保留密碼的HMAC和相應的密碼。 密鑰（摘要）；

1. 客戶端從向服務器請求隨機數開始，服務器返回密鑰和 Nonce ；
2. 客戶端計算：HMAC（HMAC（ Password ， Key ）， Nonce ）並將其發送到服務器；
3. 服務器計算：HMAC（摘要， Nonce ）並將其與接收到的值進行比較。
ol>

這可以防止重放。

我看到的主要興趣不是防止竊聽，而是要完全確保不會在其上存儲明文密碼服務器，甚至不在系統日誌中（請參閱 Twitter或 GitHub）。

注意：HMAC可以由PBKDF2代替。

實際上存在一種通過不安全連接對用戶進行身份驗證的方法：安全遠程密碼（SRP）協議。 SRP專門用於允許客戶端向服務器進行身份驗證，而中間人攻擊者無法捕獲客戶端的密碼，甚至可以重播身份驗證以稍後模擬客戶端，而不管身份驗證是否成功。此外，通過SRP成功進行身份驗證會創建客戶端和服務器都知道的共享密鑰，而MitM則不知道。此秘密密鑰可用於對稱加密和/或HMAC。

但是，SRP存在許多限制：

1. 用戶必須已經以某種安全方式進行了註冊。時尚，因為註冊過程確實需要傳輸與密碼等效的材料（儘管服務器不需要存儲它）。
2. 儘管可以嘗試使用不受信任的服務器進行SRP登錄（這是安全的）不會將您的密碼公開給該服務器，並且您將能夠知道該服務器的數據庫中沒有密碼），從不受信任的服務器加載登錄網頁是不安全的（它可能會向下發送）一個頁面，其中記錄了您的每次擊鍵並將其發送到某個地方。）
3. 儘管通過SRP成功進行身份驗證會生成安全的共享密鑰，但需要從Web應用程序中加載實際使用此密鑰的代碼一台服務器，攻擊者可能會篡改該代碼以竊取對稱密鑰並更改請求和響應。
ol>

換句話說，雖然SRP在您有一個受信任的客戶端不需要通過不安全的連接下載其代碼並且還有其他一些安全的方式來註冊用戶的情況下很有用，但是SRP不適合Web應用程序。網絡應用程序始終會從服務器下載其代碼，因此，如果與服務器的連接不安全，則MitM（或其他網絡攻擊者，例如欺騙DNS的人）可以將惡意代碼注入網絡應用程序，您無所適從，受害者，可以做到這一點。一旦有了該代碼，它就可以捕獲您輸入的任何密碼或其他數據，竊取所生成的任何密鑰，並且在您不知情的情況下篡改您發送的任何請求或收到的響應。

當然可以使用HTTP安全發送密碼。甚至有一個標準。它稱為 HTTP-Digest ，在RFC 7616中定義。它已經成為HTTP規範的一部分，已有相當一段時間了。它最初被設計為僅使用MD5消息摘要（“哈希”）算法，但是該標準的更高版本允許客戶端和服務器協商使用哪種算法。

不幸的是，存在許多問題使用HTTP摘要，最明顯的是服務器需要以明文形式獲取密碼。因此，儘管可以使用HTTP安全地傳送密碼，但是在使用時無法在服務器上安全地存儲密碼。因此，基本上，它沒有用。

如其他人所說，實施TLS會更好，因為它可以同時解決多個問題，並且具有相當的前向兼容性。

正如其他人所說的TLS！ TLS！ TLS！ （並且具有適當的密鑰長度）

但是如果您必須使用HTTP和任何服務器來實現，這是用於編程用途還是人為使用？如果是人為使用，您是在尋找基本身份驗證還是基於表格？並且您的使用是否能夠應用一些邏輯例如

如果需要的話，您可以查看以下內容：

• 使用一次性密碼鍵盤/密碼生成器（RSA密鑰卡並不便宜，如果您有那麼多錢可花，那麼您可以負擔得起TLS）
• 其他一些2要素驗證，例如SMS（不是
• 一種用於混淆密碼的簡單質詢/響應機制，例如，頁面在文本上顯示兩個數字（兩個都不標明），用戶必須以簡單的計算，例如添加到PIN的每個數字的兩個數字之間的差異，可能帶有之前和/或之後的隨機填充，例如98634572dkkgdld。更改挑戰號應該停止不是立即嘗試的重播攻擊，但是如果攻擊者可以捕獲足夠的嘗試，他們也許可以解決。您不會在面向用戶的腳本中添加任何混淆邏輯，要么會看到“ cos，如果方案太複雜，您的用戶就會更討厭您。”

我希望儘管使用TLS仍然如此，但是如今證書很便宜（甚至是免費的），因此令人費解的混淆方案確實沒有理由再存在了。