Web前端密碼加密是否有意義？

01-03

既然前端代碼都是直接可以看到的，那加密是否還有意義？

我總結一下，首先大家都知道走 HTTPS 才是目前唯一負責的方式。

但在 HTTP 環境下，無論如何都可能會被劫持流量，不管前端做不做加密都會被輕易成功登錄。這個時候保護密碼明文是否有意義？有人站隊前端加密無意義，考慮的是這個加密對本站的安全性沒有任何提升；但如果你是從保護用戶的角度出發，用戶多站點共享密碼是現狀，你在沒法改變這一點的情況下，如果能夠保護密碼明文，至少降低了一點該用戶其他網站（即使是 HTTPS 的網站）被一鍋端的風險。這怎麼能說完全沒有意義？

有人說 HTTP 流量可以直接注入腳本，直接拿到用戶輸入的密碼，這沒錯。但是注入腳本就是代價，只要能夠提高一點點門檻就不能說沒有意義，很多時候是這些收益和成本之間的權衡。

另外，贊同 @Rix Tox，即使在 HTTPS 環境下，使用前端加密也並非沒有意義，甚至對於保護用戶隱私而言有很大價值。

很多回答分析得都挺對，但最後得出的結論我不能認同。0 就是 0，0.1 就是 0.1。

補充一下，關於 @eldereal 的回答，他實際在論證的論點其實並不是「密碼在前端加密完全沒有意義」，而是「前端加密不能改善當前網站本身的安全性，不能因此降低後端的安全等級」。他自己的回答里都清清楚楚寫了「這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上」，不知道為何還要強行縮小問題的範圍，得出「完全沒有意義」的結論。也許「保護自己網站的用戶密碼明文免受社會學攻擊」對於某些人來說是完全沒意義的？

有幾個答案有很大的問題，為防止有人受到誤導，我覺得有必要說一下：

密碼在前端加密完全沒有意義，對密碼系統的安全性不會有任何提高，反而會引發不必要的麻煩。

首先，做前端開發的人需要知道，前端系統的控制權是完全在用戶手裡的，也就是說，前端做什麼事情，用戶有完全的控制權。

假設如同 @陳軒所說，前端做過了md5，後台就不用做了，這個做法會有什麼後果？如果某一天，這個系統的資料庫泄露了，黑客就直接拿到了每個用戶的密碼md5值，但此時，由於黑客知道密碼是在前端進行哈希的，所以他不需要爆破出該md5對應的原文是什麼，而是直接修改客戶端向伺服器發出的請求，把密碼欄位換成資料庫中MD5就可以了，由於與資料庫中記錄一致，直接就會登錄成功。這跟直接存儲明文密碼沒有任何區別！！！所以不管前端是不是加密了密碼，後台使用安全的哈希演算法對內容再次轉換是非常有必要的。（MD5可不行，要用bcrypt，我之前回答過一個類似的：隨著顯卡性能的高速發展，目前的快速Hash演算法是否已經變得不夠安全了？）

這個回答還有一個人贊同，希望大家別被錯誤答案誤導了。

另外一個答案 @林鴻所說，在非安全HTTP連接上，可以防止原始密碼被竊聽。但問題在於由於你的登錄系統接受的哈希過的密碼，而不是原文，竊聽者根本不需要原始密碼，只要通過哈希結果就可以偽造請求登錄系統。這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上，而不能改善該網站的安全性。所以不管前端是不是加密了密碼，使用HTTPS安全連接進行登錄都是非常有必要的。

以上我說的兩點，合起來看就是：不管前端是否加密了密碼，都不能以此為假設，讓後端設計的安全等級下降，否則就會有嚴重的安全問題。實際上，前端進行密碼加密，可以看做幫助用戶多進行了一次原文的轉換，不管用了什麼加密演算法，算出來的結果都是密碼原文，你該如何保護用戶的原始密碼，就該如何保護此處的加密結果，因為對你的登錄系統來說，它們都是密碼原文。

以上這些，說明了密碼加密是沒有什麼意義的，接下來，我要說明前端加密會帶來什麼問題。

有些人會認為前端進行了加密，可以降低後台的安全性需求，這種錯誤的觀念會造成系統的安全漏洞。實際上，你不能對前端做任何的假設，所有跟安全相關的技術，都必須應用在後台上。
前端進行加密會造成頁面需要js腳本才能運行，那麼假設你的系統需要兼容不能運行js的客戶端，就必須再設計一個使用原文的登錄介面。
由於前端是不是加密，所有安全機制都必須照常應用，所以為系統增加這樣的複雜性是完全沒必要的，即使傳輸明文密碼，只要正確使用了HTTPS連接和伺服器端安全的哈希演算法，密碼系統都可以是很安全的。

看了這些回答，嚇得我一身冷汗。

密碼學不要自己造輪子！

說前端加密防中間人的，請不要信任他們的產品。被 ISP 插廣告還插的不夠爽？都 2017 了，請給你們產品加上 HTTPS，不要繼續坑害用戶了。用戶隱私又不是只有密碼，你們不用 HTTPS 是不是還要自己整個全套前端加密協議？

說伺服器存密碼 MD5 不加鹽的，也請不要信任他們。拖庫拖的就是你，當然前提是你們糟糕的產品居然有很多人用。

所以 @eldereal 說的都是對的，@Rix Tox 舉的用例也是對的，就是所謂的端對端加密，伺服器只存加密後的數據，也幫助公司規避政府要求解密用戶數據的風險。Dropbox 是端對端加密，但是他們有你的密鑰……

請做產品的不要太摳，該雇幾個懂安全的碼農還是得雇。為什麼別人創業能成功，你就不行，你還以為只是運氣？

所有說重放攻擊的、中間人、劫持等等的都是不認真看答案的。密碼學跟網路安全還是差得很遠的兩個專業，密碼學的很多應用場景其實跟網路安全並無太大關係。

我就針對 @eldereal 「密碼在前端加密完全沒有意義」的觀點舉一個反例。

前端加密的意義不是為了防止中間人，而是提供一種隱私保護服務。

考慮下面的應用場景：

Client 想要在 Server 上安全存儲一份數據 M，使用密鑰 K，那麼我們可以採用這樣的流程：

1. Client 在前端對數據 M 進行 AES 加密： C = Encrypt(M, K)
2. Client 計算出密鑰 K 的 Hash： H = bcrypt(K)
3. Client 計算出數據 M 的 Hash 保存作為文件標識： ID = sha1(M)
3. Client 將 (C, H, ID) 發送給 Server，Server 進行儲存

當 Client 想要從 Server 上提取數據可以採用這樣的流程：

1. Client 計算出密鑰 K 的 Hash： H = bcrypt(K)
2. Client 將 (ID, H) 發送給 Server，Server 匹配驗證 ID 和 H 值後把對應的 C 密文發給 Client
3. Client 在前端對密文 C 進行 AES 解密： M" = Decrypt(C, K)
4. Client 計算出數據 M" 的 Hash 與 ID 進行驗證： ID =?= sha1(M") 如果一致則表示獲取到的文件與原始文件一致 M == M"

在這組流程中，我們可以看到，Server 拿到的的信息只有 (C, H, ID)，從而能夠保證就算 Server 上的信息洩露也不會涉及到任何明文。

上述的流程有很多國外的網盤都在用，比如 Dropbox、Mega、PutDrive 等等，當然他們是在 HTTPS 通道上使用的，採用前端加密的目的也不是為了防止中間人，而是一種隱私保護服務。

===============================

@黎博 @王超 @fox fun 你們也許知道點網路安全，但是涉及到密碼學卻是不一樣的。不是逆向不逆向得了的問題，密碼學演算法基本都是公開的。也不是C/S; B/S什麼架構的問題，題目並沒有限制這個方面。

W3C雖然制定了前端加密的介面標準，但是並不限制應用場景。你們僅僅從自己涉及到的業務說這東西沒用是片面的。

密碼學的應用相當廣泛，「前端加密」不是單單只做個MD5 Hash這麼簡單的東西，你們覺得沒用那是因爲你們還沒遇到要用到的場景。在我看來國內的公司基本上都用不到「前端加密」，所以對國內行業來說，「前端加密」沒用是可以接受的。

但是放在很多國外的服務來說，「前端加密」的應用比比皆是。舉些例子：

Mega.nz、Dropbox 這些網盤服務提供端對端加密，也就是說你上傳的數據就連服務端都無法查看明文。這時候你不用「前端加密」要怎麼實現？

再來看看這個端對端加密的Markdown編輯器：standard notes app, un-standard every other way. 你告訴我不用「前端加密」怎麼實現？

再看看玄星回答的這個問題「是否存在一種加密演算法：加密後上傳的文件，伺服器無法查閱內容，但是可以幫你找回密碼？ - 玄星的回答 - 知乎」你們仔細思考一下不靠「前端加密」怎麼實現？

更不用說還有人打算把區塊鏈、智能合約在前端上實現了，類似的應用太多了，怎麼能說沒有意義呢？

一切設計都要基於目的。比如對於前端加密的意義，應該先問加密的目的，然後再看是否有必要。在非HTTPS下，很難將可登錄的密碼保護好，這一點如 @eldereal所說的，不管前端是否進行摘要演算法轉化，對於後端的系統來說，可登錄的都是你傳輸到後端的部分。

所以對於後台系統來說，安全性還是要基於後台系統總體進行設計，而無關你前台的部分。

至於前台要不要加密，可以單獨從前台的角度考慮，因為後台其實並不太在乎你傳過來的是明文還是密文，它只需要通過一些運算，然後和資料庫對上就可以了。

總結下，前台加密的結果就是假設原來黑客需要知道你的明文才能進入系統，現在不止明文，知道密文也可以登錄系統。

在前端對密碼做一次MD5，看起來是防止明文傳輸了，事實上只有一種情況下它可以提高用戶的安全性，那就是用戶在別的網站上也用和你的網站一樣的密碼。並且在任何情況下都提高不了你自己網站的安全性。

前面說的傳輸過程、內存里、日誌里……這些地方沒有明文密碼，其實都只能保護用戶本身的利益，對於自身服務的安全性是沒有提高的。因為，既然傳輸過程不是加密的，那麼包隨便發，至於發一個abc123，還是發一個e99a18c428cb38d5f260853678922e03，對你的程序沒有任何的區別，這時候你的程序都是小綿羊。

這個過程可以看做，你的用戶都用了32位字元串的密碼，如是而已。

從事實意義上講，在所有網站上用同樣密碼的用戶非常多，所以可以勉勉強強的說，這是有一丁丁點的意義的。

但即使在前端做了簽名，因為hash暴露了，也還是很容易被撞庫。

但是，對安全性沒有提高，就不做了嗎？

當然要做，因為要應付審計。

沒有意義，講一句話：必須假設提交到伺服器的所有數據都是不安全的。

=== 2017.3.6 更新 ===

請各位批判本答案的時候不要從 HTTPS 入手。

我們都強烈建議所有站都使用 HTTPS，在這裡僅討論前端加密的好處。

在我看來 HTTPS 與前端加密並不矛盾。

本文所述的前端加密指的是所有阻擋明文暴露的方法，包括散列。

@Rix Tox 講的端到端加密不包含於本答案的討論之中，因為那是必須的。。。而且答主非密碼學專業，網路安全與密碼學關係絕對是不大的= =

@顧軼靈的答案與本答案相似，即：

前端加密不是決定性的保護措施，但卻是一種有意義的低成本安全增強方案。

謝謝各位從密碼學講了這麼多，作為一個信息安全專業學生（僅僅是初學了密碼），答主並不打算從密碼學上來說前端加密有啥用。因為在我看來，前端加密在演算法透明的情況下，本身就僅僅是一種用戶隱私保護方案，避免明文暴露罷了。

各位請記住，如果東西已經丟了，那麼丟了密文總比丟了明文強。

這個思路同樣應用於散點認證，其基礎是增加攻擊成本，儘可能降低攻擊帶來的損失。

=== 原答案 ===

實名反對前面說「毫無意義」的答案。
前端加密是有好處的。
我們就討論前端 hash 的好處。

前端加密可以：
（1）避免明文密碼在傳輸中被獲取
（2）保證後端日誌等不會記錄明文密碼（也可以防止內鬼盜竊）
（3）保證後端內存中無用戶明文密碼，在 dump 等情況發生時不會出現泄露問題

我們再說一下成本問題：
（1）前端加密在不影響後端性能的情況下滿足對用戶密碼的保護
（2）前端執行一個散列運算對前端來說真心不是事，密碼這麼短，不會影響性能。
（3）與 HTTPS 的流程相比，在前端散列一下幾乎不影響網站響應速度和用戶體驗

最後，我們來說一下誤區：

（1）前端散列不意味著後端可以減少安全工作量，前端散列一般會採用較為「低功耗」的弱加密實現，而不會使用 RSA 等方法（有人使用短密鑰的 RSA 依然是不安全的）。

（2）前端加密不可以防範中間人攻擊，中間人依然可以實施重放攻擊。

@Rix Tox 的場景有意義，當K是用戶密碼或其他用戶才擁有的東西的時候，可以保證服務端保存著敏感信息卻無法獲知敏感信息的具體內容（例如密碼），看場景使用，敏感場景還是有意義

---原文---

Web前端密碼加密沒意義，或者說意義不大。

安全對抗，我們從攻擊切面來談。

B端，依賴操作系統，依賴用戶的環境，Web前端做任何加密手段，只要宿主環境不安全，都是徒然（例如中毒了記錄鍵盤操作）

傳輸層，HTTPS 已經是公認的傳輸層加密手段，必備，這個和Web前端密碼加不加密扯不上關係。

S端，後端有完整的安全對抗體系，我這裡不展開。

我就問一句，給Web前端密碼加密是為了防範什麼？

@Rix Tox 的場景，Client 手中的 K 從哪來？只有當存放 C 的 Server 拿不到 K 的時候，C才是安全的。

@王集鵠的場景，其實是假設這個站點不可信，認為一套密碼走天下的時候，總會有個別站點會泄露這個密碼，所以總是手工hash一次密碼。還是那句話，安全對抗要講攻擊點面，否則可以無限延伸開來。

沒找到其他說有意義的具體案例，有我再補充。

PS1：給多一個非密碼場景下的前端加密對抗案例，曾經3Q大戰，攻防雙方的戰場是Web版的QQ。防守方不論怎麼變化Web前端的防禦手段，攻擊者都能在短時間內破解，最終結果是，攻防雙方在短時間內頻繁迭代產品，變成一場非常消耗人力的拉鋸戰。

PS2：我看到很多評論並沒有提及密碼，沒注意看題目是否改動過，但不論如何，在Web前端做加密始終收益不大，不如跳出來多從產品層面思考攻擊者的利益訴求，從源頭進行控制。

在某些場景下是有意義的。

我們的產品是一款比特幣錢包：https://wallet.btc.com

用戶在登錄時輸入的密碼，同時會被用來解密私鑰。私鑰用於對交易進行簽名。

在啟用 HTTPS、前端沒有加密的情況下，用戶明文提交密碼後，我們的開發人員可以通過日誌、修改線上代碼等方式獲取用戶的密碼，從而產生用戶財產安全隱患。

為了解決這個問題，我們需要用戶在註冊登錄時使用鹽對原密碼做數萬次哈希運算，將其做為密碼提交給服務端，返回加密後的私鑰。用戶在發送比特幣時，需要在客戶端（Web、iOS、Android）輸入密碼，在客戶端做計算得到解密後的私鑰，之後再進行比特幣交易簽名。

要明白前端加密是否有意義，首先我們要知道，當我們在討論前端加密時，我們在談些什麼，關於這個問題，我們豈安科技的前端攻城獅做了一個詳細的解釋：

以下，乾貨來襲~

當我們在談論前端加密時，我們在談些什麼

當然在談安全。

前端加密的意義

在 HTTP 協議下，數據是明文傳輸，傳輸過程中網路嗅探可直接獲取其中的數據。如用戶的密碼和信用卡相關的資料，一旦被中間人獲取，會給用戶帶來極大的安全隱患。

另一方面，在非加密的傳輸過程中，攻擊者可更改數據或插入惡意的代碼等。HTTPS 的誕生就是為了解決中間人攻擊的問題，但如今 HTTPS 的使用情況在國內並不樂觀，基本是因為成本或者性能的考量。

那麼問題來了，

如果仍然使用 HTTP 協議，

怎麼樣一定程度保證用戶的數據安全？

前端加密，

即在數據發送前，

將數據進行哈希或使用公鑰加密。

如果數據被中間人獲取，

拿到的則不再是明文。

設想在如今公共 WIFI 流行的今天，一旦某一個 AP 的流量被攻擊者劫持，如果密碼和用戶名都是明文，那麼攻擊者將輕而易舉的使用這些資料進行 Replay 登錄。更糟糕的是很多用戶在不同的網站使用相同的賬號信息，用戶的隱私蕩然無存。

作為網站服務提供者，網站設計和開發人員應該為用戶提供相對安全的服務，這是一種責任也是一種情懷。

另外，如果前端使用哈希演算法，不僅可以幫助後端分擔部分計算壓力，還可以增加撞庫成本。具體的討論將在下文繼續。

想了解更多關於前端加密的秘密，歡迎關注微信公眾號：bigsec

等你哦

你們那些討論各種前端加密方案的真的夠了，開個介面讓用戶上傳自己的公鑰有多難？不比你們想一大堆破辦法強多了？

只要是明文傳輸，就沒什麼意義。

Over!

有意義，而且很有必要。當然我這裡針對的不僅僅是密碼，比如用戶私鑰等其他任何敏感信息。

你沒有遇到類似需要前端加密的場景，自然就覺得沒有意義。

後端確實不能信任前端的任何輸入，但是並不代表前端也就一定需要無條件的信任後端。

很典型的一個應用場景就是比特幣的錢包網站，具體交易過程這裡不再追溯，可以參考著名的比特幣錢包Blockchain的設計機制。

很多人說大部分情況HTTPS就夠了，不需要前端加密，這是一種無條件信任後端的思想，並不可取。諸君請看：

據說 Cloudflare 泄露用戶 HTTPS session 長達數月，涉及 Uber，1password，1password。。1password。。

微博

最近就遇到了這個問題，起初我也自己動搖過前端密碼加密到底有沒有意義，但最終還是決定，修復該bug，前端加密傳輸用戶密碼。主要原因如下：

1、明文傳輸，本身就不符合安全常識。

2、明文傳輸，在中間人攻擊發生時，無門檻，直接獲取明文密碼進行登錄

3、至於前面朋友提到的，直接md5發送，其實完全可以帶上一個有效期token＋加密後的密文密碼來保障，這樣即使你直接抓到了加密的密文，直接replay，此時token也過期了，無法完成登錄的。

當然，萬無一失的密碼加密傳輸，恕我能力有限，還沒有找到這樣的方案，如有請一定賜教，謝謝

必須是有意義的！

最大的意義就是保護用戶的隱私 -- 明文密碼

就算服務商的通訊被劫持（非 HTTPS 或證書泄露）、數據被拖庫（出現安全漏洞）、內部員工查詢，用戶的明文密碼也不會被泄露

對用戶是一種負責的態度。

哪些說「密碼在前端加密完全沒有意義」的同學 Too young Too simple。

如果覺得「保護用戶隱私沒有意義」不是懶就是壞。

我會告訴你：登錄之前密碼自己做 hash 嗎。相信別人，不如相信自己。

不贊同樓主的話，前端加密有意義並且有必要，至於為什麼很多人不做，其實是一種成本性能權衡。前端的加密手段非常多，樓下只是選了倆種最基礎的加密來說明自己的觀點，而這倆種加密恰好有作者說明的這些問題。需要說明的是前端加密需要後端的配合，任何一種前端加密都需要後端配合。除了答主說的哈希演算法和加鹽之外，還有一些非對稱的加密演算法，使用公鑰和私鑰，動態口令計算，驗證碼混合校驗等等，都能更好的保證用戶的隱私和安全。

所有的加密演算法都是公開的！那我們是不是在做沒有意義的事情？

加密是一個很好玩兒的概念能做很多事。比如：我有一個密碼，我想讓你知道我有，但是我不直接告訴你這個密碼。 zéro knowledge

還是有點意義的。密碼作為密文傳播至少不會對用戶造成二次損害……丟了我們站的密碼，結果也能去其他站用同樣密碼登陸什麼的。

嘛……聊勝於無

我不是搞前端的，也不是搞安全的，不過想到能不能做成ppp協議的chap一樣。

如果不使用HTTPS

登錄前伺服器發個隨機值過來給用戶，用戶把密碼和隨機值做MD5，發送給伺服器，伺服器也這樣做，再對比。這樣不就可以避免被抓包搞重放攻擊。