雲霄情歌-smile
前端加密心理安慰
前端加密你無非是想讓第三方即便攔截到數據包也沒有任何卵用，但是如果我可以攔截你的數據包……呵呵噠！！！這不就是中間人攻擊嗎！！
前端加密只有在啟用https時才有用，否則中間人直接替換你js內容沒有絲毫卵用。https才是王道。
關於中間人 比如我虛擬一個wifi免密熱點 只要連接上我這個wifi所有未經過https的流量和數據都是對我直接開放的，不只是上行，下行也一樣。網站發送到你瀏覽器的數據一樣我也可以修改後才讓你看見，你的加密js早讓我給你替換掉了。
結論 只有https才是王道
張家老九989
首先，我們要記住：在網絡中任何場景下的加密都是有意義的！前端針對密碼的加密同樣如此。
我們要知道，HTTP協議有兩個特性：
無狀態
-
信息在網絡傳輸過程中是透明的
HTTP協議不像HTTPS協議，HTTP協議中所有信息都是明文的，此時如果在傳輸過程中被攔載，像密碼啥的黑客一看，就知道了。
所以很多站點在沒有啟用HTTPS時，也會對前端的密碼做加密處理，比如騰訊QQ空間的帳號密碼登錄、還有其它網站，當我們在輸入密碼時，提交表單後，經常會看到密碼框裡的密碼長度一下子就變長了，其實就是在我們提交表單時，前端對密碼做了加密處理再賦值給密碼字段，所以表象上看就是密碼框裡的黑點點變多了。
當在前端對密碼做了加密處理，此時即使信息在傳輸過程中被竊取，第三方看到的是加密後的密碼，他把這個密碼拿去是沒用的，因為這個加密串是有時間和其它一些特徵的，在其它電腦/IP上提交服務端是驗證不通過的。
最後，就算是WEB前端密碼加密，不能簡簡單單用MD5對密碼進行加密，必須要加一些特徵字符在裡面，另外也要限制一下時效，防止加密後的密文一直有效。如果能用HTTPS協議請一定用HTTPS協議。
網絡圈
加密這個說法非常籠統，具體來說，一般分下面幾種情況
一 你想對前端的一些機密數據，頁面進行加密，防止非法人員獲取。
這種情況，前端加密毫無意義，因為你只有同時在前端寫入解密程序，其他的人才能看得到，否則所有人不管非法不非法都無法獲取信息。這就等於你必須把鎖和鑰匙綁在一起，在好的鎖也沒用。
對於一些安全性要求特別高的web，唯一的方法就是藉助額外的硬件實現。比如利用Ukey 實現加密。
二 你想呵呵前端代碼加密，防止別人獲取
這個同樣是毫無用處的，因為瀏覽器是不可能識別加密的網頁的，所以你必須同時提供解密程序。
所以，一般重要的js源程序，只需要做混淆就行，加密多此一舉，毫無意義。
三 對前段和後端通訊的過程加密
這個是有意義的，並且推薦這樣做。
最好的解決方法是採用非對稱加密算法。前端只保存公匙，用來對向後臺傳輸的數據加密。 而後端只保存私匙，用來解密。
由於非對稱算法的特點，你即使獲得了鑰匙頁無法進行解密，所以是比較安全的。
當然，雖然無法解密，但是可以獲取數據包，偽造偽造請求，再發送給服務器，這個就叫中間人攻擊。
防止中間人攻擊得方法就是，把你傳送的數據在加密前，先用md5進行簽名，然後把簽名和密文一起傳送回後端。後端解密後，再校驗簽名，即可判斷信息是否被篡改。
如果信息不能篡改，入侵者還可以截獲你的數據包，原封不動的發回給服務器。這個叫做重放攻擊
避免重放攻擊的方法，是在前端加密請求時候，在請求中插入一個時間戳。後端判斷收到請求的時間間隔，超過一定時間的請求即為重放攻擊。
當然，傳輸最佳的加密方案還是使用Https
shawn25
明文傳輸的是第三方的密碼：Apple ID 與密碼。因為這個是用戶在另一個網站的數據，如果加密之後，雖然攻擊者可以通過重放攻擊重新進行登錄，但是加密情況下無法獲取到原始的 Apple ID 的賬號和密碼。不加密的話如果HTTP請求被攔截的話就可以知道用戶的原始密碼了，這是一件要不得的事情。於你網站本身來說，這個問題應該不大，因為如果被攔截了，不管怎樣攔截者只要查看源碼，模擬請求之後都能登陸上。但是因為很多用戶目前來說基本上來說不會一個網站一個密碼，而是對應著多個賬戶的。所以如果知道了用戶的原始密碼，結合社會工程學，能幹的事情就挺多了。
加密更安全，不是為了完全阻擋攻擊，而是為了提高攻擊的成本，降低被攻下的概率。
十是世紀
任何形式的加密都是有意義的，只是意義大跟意義小的問題。雖然前端加密相當於加密算法公開了。但是要真找到逆運算也並非易事，你能截取加密後的數據，但是沒法得到明文，這種攻擊的危害就大打折扣。但是如果是登錄驗證這種場景，就算不能得到明文，加密後的數據得到後仍然能模擬以被攻擊者的身份登錄系統，這樣又潛在很大的安全隱患。所以，前端*加密獨立來看是有意義的，如果跟https比起來就是沒意義的。
oo全球通oo
這個話題現在是很有爭議的。是否有意義肯定是從網站安全的角度，而安全又是個很廣的概念，每個人心中都有一個哈姆雷特，我們後面再一一分析。先拋出我的觀點：Web前端密碼加密是有意義的。
反方觀點一直從加解密的角度分析這個問題，認為加密密鑰和算法都保存在前端，攻擊者通過查看js源碼就能得到算法和密鑰，加密多此一舉，還浪費性能。只要網站是https的，就能防止傳輸鏈路上的第三方監聽導致的密碼洩露，不需要額外在前端再來一層加密。另外還有人認為前端加密後還是防不住中間人重放攻擊，攻擊者還是能在不解密的情況下登錄劫持到的用戶賬號。不知道我對反方觀點總結的是否全面，歡迎大家持不同意見在評論進行補充。
我來闡述我的觀點，安全問題要考慮的問題很多，除了自己其他都是假想敵，都不可信。整個系統的短板往往是攻擊者最喜歡攻擊的目標，這個就是安全最著名的理論——木桶原理。
用戶登錄密碼從前端用戶輸入到後端入庫會有哪些風險？
首先用戶鍵盤敲的肯定是明文，這個登錄框如果是釣魚假冒網站，或者是網站本身存在xss漏洞被攻擊者前端劫持了登錄框，從我們這裡討論的加密技術上，怎麼防都防不住的，攻擊者肯定都能獲得明文。我們就不討論這個風險了，既然前端加密，我們默認前端可信。
然後接下來就是傳輸可信的問題了，從前端到後端，整個通道，可能要繞大半個中國。上面說了都可以依賴於https傳輸，解決的問題是第三方通過攔截數據包分析出明文密碼的問題。這個沒有什麼好爭辯的，https就是幹這個事情的，前端不加密傳輸在https裡面的數據第三方肯定拿不到的，否則整個密碼學體系就崩潰了。
那我們是不是就不需要前端加密了呢？非也，因為在安全的角度，兩端也是不可信的。不加密解決不了兩端對明文密碼的洩露。
我們先考慮用戶不可信的問題。如果用戶就是攻擊者呢？這個現象存在於很多web測試代理抓包場景中，https網站想代理抓包，就需要設置瀏覽器代理並且信任代理軟件ca證書，瀏覽器類似於把抓包軟件作為後端，真正的後端把抓包軟件作為前端，抓包軟件作為用戶主動設置的中間人能夠成功在自己電腦上破掉https加密。這樣做的好處是什麼呢，只能看到自己輸入的明文密碼？那就圖樣圖森破了，獲取了整個登錄請求的http包，如果有用戶密碼對字典，就可以很簡單地對後端進行批量爆破了，安全界叫“撞庫”，這幾年這麼多數據庫被脫庫，我們應該重視這個問題。
前端加密並不能完全解決撞庫問題，但是能提高攻擊成本。任何能提高攻擊成本的方案都是有意義的，阻擋了小白黑客，那些高級黑客還是能利用前端的加密算法，對自己的字典密碼進行處理。所以還要加入一次性驗證碼放入加密算法中進行防重放攻擊，我看過一篇文章講的是QQ密碼的前端加密流程，非常複雜，要知道每天都有成千上萬的黑客盯著QQ，也有各種奇葩的我們不知道的利用技術，多加一層保障總是好的。
我們再考慮的是後端的不可信問題。後端開發總認為自己比前端開發重要，有一句流傳在坊間的話，“後端不信任任何來自前端的輸入”，從安全角度，我認為前端也不應該信任任何敏感信息的輸出。很多時候出事，恰恰就出在後端。我記得github就翻車過一次，在請求日誌裡面發現了明文密碼。你不知道運維或者後臺會不會記錄包含post請求體的access log，如果不加密，log裡面就是明文密碼。公司後臺可能有各種監控系統，到時候密碼就滿天飛了。黑客突破任何一臺服務器，自己系統的密碼就有洩露的風險。
還有後端的密碼入庫問題，這個正反方都沒有異意，肯定不能明文存儲，我就不多說了，主要是防止sql注入，直接被黑客擼到數據庫裡面來了，目前站庫分離，黑客不知道後端代碼用的什麼加密方式就沒轍了。順便提一下，後面回答有些說md5是加密，明顯是概念混淆，加密是可逆的，md5這些哈希散列算法是不可逆的。
綜上所述，開發千萬不要過度依賴https，認為上了https就天下太平了。任何安全措施在不過分影響用戶體驗和開發成本的情況下都是好的，有意義的。
我是一個正在學安全的開發，如有紕漏，歡迎指正！
SuperBean
前端加密很有必要的，我做的項目全程加密。
現在流行的加密方式就是：
1、前端隨機生成一個32位字符串，用於AES對稱加密方式對加密傳輸的內容進行加密
2、使用RSA公鑰對隨機密碼進行加密，和第一步的內容組裝後，再用RSA加簽
這樣傳輸中即使被截取一般也不會識別裡面的內容
後端接收到報文，進行驗籤解密就行了
樂風輕舞聲
要求高的，比如銀行網站的登入帳號密碼都會加密。http是明文傳輸的，所以加密是非常有意義的。我就用js寫過rsa用來對錶單數據加密。
另外說明一下，前端常見的base64只是一種編碼方式，不具有加密效果。
Md5是信息摘要，同樣不具加密效果。
Base64是為了方便傳輸，md5主要用於驗證數據。而且md5是有缺限的，存在不同的數據，摘要相同的可能。
白衣有話
前端密碼加密 是為了防止在密碼路過DNS期間 被惡意劫持 ，如果不加密路過DNS是非常危險的，因為有好多層DNS需要經過，加密了以後，這是DNS拿到了，加密以後的密碼，也是沒有用的，等到了服務器端，夫妻在經過一次加密，確保密碼的安全。比如在前端用MD5加密，到了服務器可以用sh加密。
用戶59452101419
很有意思的問題，我認為既有意義，也無意義。
什麼意思呢？
其實這個問題就像大家都知道大部分門鎖都可以無鑰匙被打開，那麼你能說門鎖就沒意義了嗎？
我認為的有意義是前後端在安全信道的上進行通信，前端加密相當於多加一道鎖，肯定會提升一定的安全性；
我認為的無意義是前後端在不安全信道上（中間人攻擊）進行通信，即使進行加密，依然不肯能夠保證密碼安全；
下面我舉個經典的Alice、Bob、Mallory三人通信的例子來說明一下：
假設有兩個人Alice（前端）和Bob（服務端）要進行通信，另外Mallory（中間人）在中間隨時準備竊聽他們的會話信息。
Http環境
前端不加密的情況下：
Alice向Bob請求建立通信，這時候Mallory在中間竊聽到了Alice的請求，於是偽裝成Bob與Alice建立連接，Alice發送密碼就會被Mallory拿到造成密碼洩露。
前端加密的情況下：
因為前端代碼不安全，所以我認為一般不會採用對稱加密的方式。這裡我就大膽首先假設一下前後端加密算法是非對稱加密算法，比如RSA。
Alice向Bob請求建立通信，並且要獲取Bob的密鑰對的公鑰用於密碼加密；
此Mallory竊聽到了Alice的請求，於是將自己的公鑰給了Alice，並與Alice建立連接；
Alice用Mallory的公鑰將密碼加密後傳給了Mallory，Mallory收到加密數據後拿私鑰解密得到密碼。
有人說既然Http不安全，那我們就用安全的Https進行通信嘛！
Https環境
其實Https環境也不能保證絕對安全，在某些特定情況下也會存在中間人攻擊。
說兩種比較常見的攻擊方式：
方式一：SSLSniff
攻擊流程：
Alice首先向Bob請求進行Https會話，並要求Bob返回Https公鑰；
Mallory竊聽到Alice的請求，於是偽裝成Alice將請求轉發給Bob；
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鏈接的信息；
Mallory竊聽到Bob的返回結果，將其中重定向的Https鏈接改成了Http鏈接，並轉發給了Alice；
Alice收到已經被Mallory篡改過的返回後以為已經與Bob建立了安全的Https會話，其實只是與Mallory建立了不安全的Http會話，發送密碼的話自然會被Mallory拿到。
總結
綜上分析，我認為前端密碼加密既有意義，也無意義。有意義在於加密過程就相當於多加一道鎖，肯定會提升一定的安全性；無意義在於前端密碼加密在提升安全性的同時並不能絕對保證密碼不被竊取。
“分享乾貨，收穫快樂”
我是萌新程序員成長日記，喜歡我的文章歡迎 轉發 及 關注，我會經常與大家分享工作當中的實用技巧與經驗。
