加密這個說法非常籠統，具體來說，一般分下面幾種情況

一 你想對前端的一些機密資料，頁面進行加密，防止非法人員獲取。

這種情況，前端加密毫無意義，因為你只有同時在前端寫入解密程式，其他的人才能看得到，否則所有人不管非法不非法都無法獲取資訊。這就等於你必須把鎖和鑰匙綁在一起，在好的鎖也沒用。

對於一些安全性要求特別高的web，唯一的方法就是藉助額外的硬體實現。比如利用Ukey 實現加密。

二 你想呵呵前端程式碼加密，防止別人獲取

這個同樣是毫無用處的，因為瀏覽器是不可能識別加密的網頁的，所以你必須同時提供解密程式。

所以，一般重要的js源程式，只需要做混淆就行，加密多此一舉，毫無意義。

三 對前段和後端通訊的過程加密

這個是有意義的，並且推薦這樣做。

最好的解決方法是採用非對稱加密演算法。前端只儲存公匙，用來對向後臺傳輸的資料加密。 而後端只儲存私匙，用來解密。

由於非對稱演算法的特點，你即使獲得了鑰匙頁無法進行解密，所以是比較安全的。

當然，雖然無法解密，但是可以獲取資料包，偽造偽造請求，再發送給伺服器，這個就叫中間人攻擊。

防止中間人攻擊得方法就是，把你傳送的資料在加密前，先用md5進行簽名，然後把簽名和密文一起傳送回後端。後端解密後，再校驗簽名，即可判斷資訊是否被篡改。

如果資訊不能篡改，入侵者還可以截獲你的資料包，原封不動的發回給伺服器。這個叫做重放攻擊

避免重放攻擊的方法，是在前端加密請求時候，在請求中插入一個時間戳。後端判斷收到請求的時間間隔，超過一定時間的請求即為重放攻擊。

當然，傳輸最佳的加密方案還是使用Https

這個話題現在是很有爭議的。是否有意義肯定是從網站安全的角度，而安全又是個很廣的概念，每個人心中都有一個哈姆雷特，我們後面再一一分析。先丟擲我的觀點：Web前端密碼加密是有意義的。

反方觀點一直從加解密的角度分析這個問題，認為加密金鑰和演算法都儲存在前端，攻擊者透過檢視js原始碼就能得到演算法和金鑰，加密多此一舉，還浪費效能。只要網站是https的，就能防止傳輸鏈路上的第三方監聽導致的密碼洩露，不需要額外在前端再來一層加密。另外還有人認為前端加密後還是防不住中間人重放攻擊，攻擊者還是能在不解密的情況下登入劫持到的使用者賬號。不知道我對反方觀點總結的是否全面，歡迎大家持不同意見在評論進行補充。

我來闡述我的觀點，安全問題要考慮的問題很多，除了自己其他都是假想敵，都不可信。整個系統的短板往往是攻擊者最喜歡攻擊的目標，這個就是安全最著名的理論——木桶原理。

使用者登入密碼從前端使用者輸入到後端入庫會有哪些風險？

首先使用者鍵盤敲的肯定是明文，這個登入框如果是釣魚假冒網站，或者是網站本身存在xss漏洞被攻擊者前端劫持了登入框，從我們這裡討論的加密技術上，怎麼防都防不住的，攻擊者肯定都能獲得明文。我們就不討論這個風險了，既然前端加密，我們預設前端可信。

然後接下來就是傳輸可信的問題了，從前端到後端，整個通道，可能要繞大半個中國。上面說了都可以依賴於https傳輸，解決的問題是第三方透過攔截資料包分析出明文密碼的問題。這個沒有什麼好爭辯的，https就是幹這個事情的，前端不加密傳輸在https裡面的資料第三方肯定拿不到的，否則整個密碼學體系就崩潰了。

那我們是不是就不需要前端加密了呢？非也，因為在安全的角度，兩端也是不可信的。不加密解決不了兩端對明文密碼的洩露。

我們先考慮使用者不可信的問題。如果使用者就是攻擊者呢？這個現象存在於很多web測試代理抓包場景中，https網站想代理抓包，就需要設定瀏覽器代理並且信任代理軟體ca證書，瀏覽器類似於把抓包軟體作為後端，真正的後端把抓包軟體作為前端，抓包軟體作為使用者主動設定的中間人能夠成功在自己電腦上破掉https加密。這樣做的好處是什麼呢，只能看到自己輸入的明文密碼？那就圖樣圖森破了，獲取了整個登入請求的http包，如果有使用者密碼對字典，就可以很簡單地對後端進行批次爆破了，安全界叫“撞庫”，這幾年這麼多資料庫被脫庫，我們應該重視這個問題。

前端加密並不能完全解決撞庫問題，但是能提高攻擊成本。任何能提高攻擊成本的方案都是有意義的，阻擋了小白駭客，那些高階駭客還是能利用前端的加密演算法，對自己的字典密碼進行處理。所以還要加入一次性驗證碼放入加密演算法中進行防重放攻擊，我看過一篇文章講的是QQ密碼的前端加密流程，非常複雜，要知道每天都有成千上萬的駭客盯著QQ，也有各種奇葩的我們不知道的利用技術，多加一層保障總是好的。

我們再考慮的是後端的不可信問題。後端開發總認為自己比前端開發重要，有一句流傳在坊間的話，“後端不信任任何來自前端的輸入”，從安全形度，我認為前端也不應該信任任何敏感資訊的輸出。很多時候出事，恰恰就出在後端。我記得github就翻車過一次，在請求日誌裡面發現了明文密碼。你不知道運維或者後臺會不會記錄包含post請求體的access log，如果不加密，log裡面就是明文密碼。公司後臺可能有各種監控系統，到時候密碼就滿天飛了。駭客突破任何一臺伺服器，自己系統的密碼就有洩露的風險。

還有後端的密碼入庫問題，這個正反方都沒有異意，肯定不能明文儲存，我就不多說了，主要是防止sql注入，直接被駭客擼到資料庫裡面來了，目前站庫分離，駭客不知道後端程式碼用的什麼加密方式就沒轍了。順便提一下，後面回答有些說md5是加密，明顯是概念混淆，加密是可逆的，md5這些雜湊雜湊演算法是不可逆的。

綜上所述，開發千萬不要過度依賴https，認為上了https就天下太平了。任何安全措施在不過分影響使用者體驗和開發成本的情況下都是好的，有意義的。

很有意思的問題，我認為既有意義，也無意義。

什麼意思呢？

其實這個問題就像大家都知道大部分門鎖都可以無鑰匙被開啟，那麼你能說門鎖就沒意義了嗎？

我認為的有意義是前後端在安全通道的上進行通訊，前端加密相當於多加一道鎖，肯定會提升一定的安全性；

我認為的無意義是前後端在不安全通道上（中間人攻擊）進行通訊，即使進行加密，依然不肯能夠保證密碼安全；

下面我舉個經典的Alice、Bob、Mallory三人通訊的例子來說明一下：

假設有兩個人Alice（前端）和Bob（服務端）要進行通訊，另外Mallory（中間人）在中間隨時準備竊聽他們的會話資訊。

前端不加密的情況下：

Alice向Bob請求建立通訊，這時候Mallory在中間竊聽到了Alice的請求，於是偽裝成Bob與Alice建立連線，Alice傳送密碼就會被Mallory拿到造成密碼洩露。

前端加密的情況下：

因為前端程式碼不安全，所以我認為一般不會採用對稱加密的方式。這裡我就大膽首先假設一下前後端加密演算法是非對稱加密演算法，比如RSA。

Alice向Bob請求建立通訊，並且要獲取Bob的金鑰對的公鑰用於密碼加密；

此Mallory竊聽到了Alice的請求，於是將自己的公鑰給了Alice，並與Alice建立連線；

Alice用Mallory的公鑰將密碼加密後傳給了Mallory，Mallory收到加密資料後拿私鑰解密得到密碼。

有人說既然Http不安全，那我們就用安全的Https進行通訊嘛！

其實Https環境也不能保證絕對安全，在某些特定情況下也會存在中間人攻擊。

說兩種比較常見的攻擊方式：

方式一：SSLSniff

攻擊流程：

Alice首先向Bob請求進行Https會話，並要求Bob返回Https公鑰；

Bob並不會知道請求到底是來自於Alice還是Mallory，於是將公鑰傳送給了Mallory；

Mallory用自己的公鑰替換了Bob的公鑰返回給了Alice；

Alice用自以為是Bob的公鑰對密碼進行了加密，併發送給Bob；

Mallory竊聽到Alice的請求後拿自己的私鑰進行解密得到密碼；

此方式是利用了Alice無法確定拿到的公鑰是來自於Bob這一漏洞。

但是也不用太過擔心，要想實際發起攻擊也不是那麼簡單的，有一個證書信任的問題，因為Mallory自己偽造的證書預設是不受瀏覽器信任的，需要客戶端手動信任才能實施攻擊。

方式二：SSLStrip

這個攻擊相比SSLSniff要複雜一點，並且不需要偽造證書就可以達到攻擊目的。

SSLStrip攻擊也需要一些特定場景才可以實現：我們一般在瀏覽器中輸入網址時並不會在連結前面加https://，因而向伺服器傳送了Http請求，伺服器會返回302狀態碼並重定向到Https，而SSLStrip正是利用這一點實施的中間人攻擊。

攻擊流程：

Alice由於沒有加https://，所以無意中向Bob發起了建立Http會話的請求；

Bob收到Alice的請求後返回一個包含302狀態碼重定向到Https連結的資訊；

Alice收到已經被Mallory篡改過的返回後以為已經與Bob建立了安全的Https會話，其實只是與Mallory建立了不安全的Http會話，傳送密碼的話自然會被Mallory拿到。

綜上分析，我認為前端密碼加密既有意義，也無意義。有意義在於加密過程就相當於多加一道鎖，肯定會提升一定的安全性；無意義在於前端密碼加密在提升安全性的同時並不能絕對保證密碼不被竊取。

“分享乾貨，收穫快樂”

有意義，大體來說：

1.對於整個網站，在各個端都要做層層限制，在web端就是做第一層加密，雖然web端加密方式不多，或者容易被破解，但是有必要做第一層的打包壓縮編譯，做一些混淆程式碼的工作，後面的加密就是後端的事

2.加密過程主要為了做一些預防，比如xss攻擊，簡訊碼頻繁傳送，跳過登入限制等等

綜上，web安全還是很有意義的，以上就是做個大體的描述，細節方面可以參考web安全相關書籍

首先，我們要記住：在網路中任何場景下的加密都是有意義的！前端針對密碼的加密同樣如此。

我們要知道，HTTP協議有兩個特性：

無狀態

資訊在網路傳輸過程中是透明的

HTTP協議不像HTTPS協議，HTTP協議中所有資訊都是明文的，此時如果在傳輸過程中被攔載，像密碼啥的駭客一看，就知道了。

所以很多站點在沒有啟用HTTPS時，也會對前端的密碼做加密處理，比如騰訊QQ空間的帳號密碼登入、還有其它網站，當我們在輸入密碼時，提交表單後，經常會看到密碼框裡的密碼長度一下子就變長了，其實就是在我們提交表單時，前端對密碼做了加密處理再賦值給密碼欄位，所以表象上看就是密碼框裡的黑點點變多了。

當在前端對密碼做了加密處理，此時即使資訊在傳輸過程中被竊取，第三方看到的是加密後的密碼，他把這個密碼拿去是沒用的，因為這個加密串是有時間和其它一些特徵的，在其它電腦/IP上提交服務端是驗證不透過的。

最後，就算是WEB前端密碼加密，不能簡簡單單用MD5對密碼進行加密，必須要加一些特徵字元在裡面，另外也要限制一下時效，防止加密後的密文一直有效。如果能用HTTPS協議請一定用HTTPS協議。

要求高的，比如銀行網站的登入帳號密碼都會加密。http是明文傳輸的，所以加密是非常有意義的。我就用js寫過rsa用來對錶單資料加密。

另外說明一下，前端常見的base64只是一種編碼方式，不具有加密效果。

Md5是資訊摘要，同樣不具加密效果。

Base64是為了方便傳輸，md5主要用於驗證資料。而且md5是有缺限的，存在不同的資料，摘要相同的可能。

假設客戶端系統沒有病毒木馬，沒有被記錄擊鍵。加密密碼是沒有必要的，應該使用HTTPS較為安全。所以實際開發對這個沒有要求的。

明文傳輸的是第三方的密碼：Apple ID 與密碼。因為這個是使用者在另一個網站的資料，如果加密之後，雖然攻擊者可以透過重放攻擊重新進行登入，但是加密情況下無法獲取到原始的 Apple ID 的賬號和密碼。不加密的話如果HTTP請求被攔截的話就可以知道使用者的原始密碼了，這是一件要不得的事情。於你網站本身來說，這個問題應該不大，因為如果被攔截了，不管怎樣攔截者只要檢視原始碼，模擬請求之後都能登陸上。但是因為很多使用者目前來說基本上來說不會一個網站一個密碼，而是對應著多個賬戶的。所以如果知道了使用者的原始密碼，結合社會工程學，能幹的事情就挺多了。

加密更安全，不是為了完全阻擋攻擊，而是為了提高攻擊的成本，降低被攻下的機率。

前端加密心理安慰

前端加密你無非是想讓第三方即便攔截到資料包也沒有任何卵用，但是如果我可以攔截你的資料包……呵呵噠！！！這不就是中間人攻擊嗎！！

前端加密只有在啟用https時才有用，否則中間人直接替換你js內容沒有絲毫卵用。https才是王道。

關於中間人 比如我虛擬一個wifi免密熱點 只要連線上我這個wifi所有未經過https的流量和資料都是對我直接開放的，不只是上行，下行也一樣。網站傳送到你瀏覽器的資料一樣我也可以修改後才讓你看見，你的加密js早讓我給你替換掉了。

結論 只有https才是王道

任何形式的加密都是有意義的，只是意義大跟意義小的問題。雖然前端加密相當於加密演算法公開了。但是要真找到逆運算也並非易事，你能擷取加密後的資料，但是沒法得到明文，這種攻擊的危害就大打折扣。但是如果是登入驗證這種場景，就算不能得到明文，加密後的資料得到後仍然能模擬以被攻擊者的身份登入系統，這樣又潛在很大的安全隱患。所以，前端*加密獨立來看是有意義的，如果跟https比起來就是沒意義的。