密碼加密在 Web 前端有意義嗎？

在前端做乙個密碼MD5，似乎可以防止明文的傳輸，其實只有一種情況可以提高使用者的安全性，那就是使用者在其他**上也使用與你相同的密碼。 無論如何都不會提高你自己的安全性**。 如前所述，明朝的傳輸過程、記憶和日誌都......這些地方沒有明文密碼，其實只能保護使用者自己的利益，自己服務的安全性並沒有提高。

因為，既然傳輸過程沒有加密，那麼包裹就是隨便傳送的，至於發乙個abc123，或者發乙個e99a18c428cb38d5f260853678922e03，跟你的程派丹訂單沒什麼區別，這個時候你的程式就是乙隻小赤北羊。 將此過程視為使用者使用的 32 位字串密碼，僅此而已。 從事實意義上講，有很多使用者在所有**上使用相同的密碼，所以可以說這有點意義。

但就算前端有符號，因為雜湊暴露了，還是很容易被塞進去的。 但是，如果你不提高安全性，你不這樣做嗎？ 當然，你必須這樣做，因為你必須處理審計。

一切都是為了目的而設計的。 比如前端加密的含義，應該先問問加密的目的，再看看有沒有必要。 在非HTTPS的情況下，登入密碼很難保護，不管前端是否轉換彙總演算法，對於後端系統來說，可以登入的就是你轉移到後端的部分。

因此，對於後台系統來說，安全應該以後臺系統為整體來設計，冰雹搜尋很好，與你的前台部分無關。 至於前台要不要加密，可以單從前台的角度來考慮，因為後台其實不太在意你是以明文還是密文形式傳送的，只需要經過一些計算，肆意攜帶，然後與資料庫匹配即可。 綜上所述，前台加密的結果是假設原來導致黑客需要知道你的明文才能進入系統，現在不僅明文，還要知道密文才能登入系統。

這沒有意義。 首先，前端開發人員需要知道，前端系統的控制權完全掌握在使用者手中，也就是說，前端做什麼，使用者就擁有完全的控制權。 據稱，前端做MD5，後端不必做，這種方法的後果是什麼？

如果有一天，系統資料庫被洩露，黑客直接獲取了每個使用者密碼的md5值，但是這一次，因為黑客知道密碼在雜湊前面，所以他不需要吹掉原來對應的md5，而是直接修改資料庫密碼欄位md5請求的客戶端傳送給伺服器， 與資料庫中的記錄匹配，您可以直接登入。這與直接儲存明文密碼沒有什麼不同！ 因此，無論前端密碼是否加密，都需要在後台使用雜湊演算法進行安全內容轉換。

MD5 不能使用 bcrypt，我和以前差不多：用圖形表示，目前快速發展的快速雜湊演算法變得不安全了？ 有乙個人同意這個答案，希望你不要被錯誤的答案誤導。

Linh說，另一方是為了防止原始密碼被利用來獲取不安全的HTTP連線。 但問題是，由於您的登入系統接受密碼而不是原始密碼，因此竊聽者根本不需要原始密碼，只要雜湊結果可以偽造登入系統的請求即可。 這樣做只會防止攻擊者在發生社交攻擊時使用原始密碼，而不會提高安全性。

因此，無論之前的密碼是否加密，都需要使用HTTPS安全連線登入。

我上面提出的兩個要點是：無論前端加密密碼如何，都不能假設這是後端設計安全等級的降低，否則可能會出現嚴重的安全問題。 其實前端的密碼加密可以看作是幫助使用者超越原來的文字轉換，不管是什麼加密演算法，計算結果都是原密碼，如何保持使用者原來的密碼為空還是受保護，這裡怎麼保護加密結果，因為你登入了系統， 它們是原始密碼。

有些人認為，前端是加密的，以減少對後台安全的需求。 這種誤解可能導致系統安全漏洞。 事實上，你不能對前端做出任何假設，所有與安全相關的技術都必須應用於後端。

前端加密將導致頁面需要 JS 指令碼才能執行，然後假設您的系統需要與無法執行 JS 的客戶端相容，您必須使用原始程式設計登入介面。 由於前端沒有加密，因此必須像往常一樣應用所有安全機制，因此完全沒有必要向系統新增這種複雜性。 即使傳輸了明文密碼，只要正確使用https連線和伺服器端安全雜湊演算法，密碼系統也會非常安全。

在前端對密碼進行加密是完全沒有意義的，它不會提高密碼系統的安全性，反而會造成不必要的麻煩。

1）加密不能解決重放的問題，雖然你傳送到伺服器的資料是加密資料，但是在黑客攔截後，加密的資料被重新傳輸，並且仍然經過驗證。直接監聽你所謂的密文，然後使用指令碼發起HTTP請求登入。

HTTP是以明文形式在網路上傳輸的，**和閘道器可以看到所有的資料，在同一區域網內也可以被嗅探，可以開啟乙個wireshark來抓取區域網的資料包來嘗試。 加密不會增加攻擊的難度，因為攻擊者不需要解密原始密碼，能夠登入就意味著目標已經達到，所以難度沒有增加。

2）由於是加密，因此用於加密的金鑰和演算法必須儲存在前端，攻擊者可以通過檢視原始碼來獲取演算法和金鑰。除非你做乙個瀏覽器外掛程式，將演算法和金鑰封裝在外掛程式中，然後在加密時以明文形式對時間戳進行混淆，否則即使黑客截獲了請求資料，在進行回放過程時也會很快失效。

JS 中的不可讀性有三個方面：壓縮、混淆和加密。 不可讀性，這是我自己發明的乙個術語，所有增加不可讀性的轉換，都可以稱為，“增加可讀性”可能是轉換的結果或目的）。

1.壓縮。

此操作的目的是使最終傳輸量（不表示數量，也不表示檔案大小）盡可能小。 常用的JS壓縮工具有：Yui Compressor、UglifyJS、Google Closure Compiler等。

通常在壓縮過程中，只改變語法，語義和控制流變化不大。

通常的做法是縮短區域性變數，等效地替換某些操作。 壓縮有助於提供一些保護，但它的作用不大，因為語義和控制流基本保持不變。

在壓縮級別上，不可讀性只是附帶傷害，而不是目的本身。

2.混淆。

此操作的目的是使**盡可能不可讀，主要用作**保護。

使**不可讀，增加分析難度，這是唯一的目的。 混淆後檔案大小是否翻倍並不重要，**的數量是否增加也無關緊要，操作速度是否慢 50% 也無關緊要。

常見的做法包括分離常量、中斷控制流、新增廢話、檢查執行時環境以及在不正確時進行打擊等。

在混淆的層面上，不可讀性是最終目標。

值得一提的是，Google Closure Compiler 的 Advance Level Compression 壓縮了類和物件的成員，其壓縮結果很難解析，可以認為是混淆的，但不是很相容。

廣告時間：我寫了js混音器，中文叫“looks like a powerful js compiler”，英文名字叫the impressive，看起來很強大的js編譯器。

3.加密。

老實說，我很難定義加密，因為網路世界中有太多的模糊性。

哪裡有加密，哪裡就有解密，這意味著加密操作是可逆的，密文是可以破譯的。

加密混淆 JS，有很多這樣的加密混淆工具。 例如，nodejs 沒問題，但需要 cmd 命令來執行加密混淆。