GWT/JavaScript客戶端密碼加密

Question

我執行我的GWT應用程序的授權，並在它下面的方式進行的那一刻：

1. 用戶註冊時，把他的證件的形式，和我將它們以明文形式發送給服務器。
2. 服務器代碼使用BCrypt散列接收到的密碼並將散列放入數據庫中。
3. 當用戶登錄時，他的密碼以明文方式發送到服務器，該服務器會根據存儲的散列進行檢查。

現在。關於這一點困擾我的事情是，我將密碼以明文方式發送到服務器，我一直認爲，如果我使用的應用程序使用我的（use-for-所有類型的）密碼，但是在客戶端加密它並不能真正爲我贏得任何東西，因爲攻擊者可以像使用密碼那樣使用散列密碼。

我一直在爲這一整天googling，看來互聯網是非常一致的，當談到這一點 - 顯然沒有什麼可以從客戶端密碼加密獲得。 This，this和this僅僅是我所討論過的討論和網頁的幾個例子，但還有很多很多更多，都說同樣的事情。

這個問題，在這所有的光，似乎有點多餘，但我希望在某個地方，某個人，將有另一個答案對我來說。

我能做些什麼，如果SSL不是一個選項，在這一點上，以減輕我的主意呢？有什麼要做，或者將實施某種客戶端加密 - 服務器 - 解密方案只是耗時的虛弱的死馬踢？

Answer 1

對於登錄，SSL應該是您的選擇，即使在這一點上。如果僅僅用於登錄，你不需要昂貴的SSL農場，但是至少你可以保護（使用所有類型的）密碼，儘管它很清楚，其餘的通信是不安全的^[*]。這可能意味着，您只需要爲一臺登錄服務器購買證書，這可以爲您節省很多錢，具體取決於證書供應商。

對於GWT，如果您無法負擔加密所有通信的費用，則由於同源策略限制，您必須將登錄名放在單獨的頁面上。

如果這仍然不是一個選項，你可以考慮通過OpenID登錄，就像stackoverflow一樣。

不能有在不安全的媒體沒有任何安全通信的一些預共享密鑰 - 通常由安裝在瀏覽器（根證書提供BTW，這很有趣/可怕的是瀏覽器，甚至整個操作系統通常通過HTTP下載）。其他系統，例如PGP，依靠先前在"Web Of Trust"建立的信任，但這只是另一種形式的預先分享的祕密。沒有辦法繞過它。

^{[*]使用SSL的一切 - 不幸 - 帶來了更多的實際問題：1）頁面加載速度慢很多，尤其是如果頁面上有很多元素。這是由於SSL誘導的往返行程和由此造成的延遲，即使是最快的SSL場也無法對付。問題得到緩解，但未通過保持活躍的連接完全消除。 2）如果您的網頁包含來自外部非HTTPS網站的元素（例如用戶插入的圖片），則許多瀏覽器將顯示警告 - 這些警告對於真正的安全問題非常模糊，因此通常對於安全網站而言是不可接受的。}

了一些其他的想法（不推薦）

假設了一下，即可以不使用SSL在所有的最壞情況。在這種情況下，或許令人驚訝的是，在傳輸密碼之前（用鹽）對密碼進行哈希處理，實際上可能比無所事事好一點。原因如下：它不能擊敗馬洛裏（在密碼學中，一個可以操縱交流的人），但至少它不會讓夏娃（一個只能聽的人）閱讀明文密碼。如果我們假設Eves比Mallorys更常見（？），那麼這可能是值得的。但請注意，在這種情況下，您應該再次將密碼再次（使用不同的鹽）進行散列，然後再與數據庫值進行比較。

Answer 2

如果SSL不是一個選項，然後很顯然你不夠關心安全;）

但嚴重的是 - 就像你提到的，密碼的客戶端加密是不是一個好主意。事實上，這是一個非常糟糕的。您不可能不可信信任客戶端插孔 - 如果攻擊者設法更改JS代碼（通過XSS或通過線路發送時），那麼您的MD5 /任何散列函數只會通過明文？更不用說，你應該使用一個好的，強大的，鹽漬的加密方法，比如bCrypt--在客戶端和前面提到的只是很慢的東西，並沒有增加應用程序的安全性。

你可以嘗試繞過一些問題：通過一些安全的方式發送哈希庫（如果這可能首先，我們現在不必打擾所有這些，我們會嗎？），通過不知何故共享服務器和客戶端之間的共同祕密，並使用它加密... 但底線是：儘可能使用HTTPS（在GWT很難混合HTTPS和HTTP）和理由（如果用戶很愚蠢，因爲您的非安全相關應用和他的銀行賬戶使用相同的密碼，那麼他/她很可能在其他一些網站上使用了相同的密碼，其中任何一個都可能導致劫持密碼）。其他方式只會讓你認爲你的應用程序比它更安全，並且使你不那麼警惕。

Answer 3

考慮使用SRP。

但是，如果一箇中間的人向你發送邪惡的javascript，而不是simpy發送你的密碼的副本給攻擊者服務器，這仍然沒有幫助。