反對認為 JS 加密沒有意義的答案。似乎在這些答案裡面，安全程度只有「安全」和「不安全」兩種等級，是麼。先簡單說下常用的 JS 加密（RSA）步驟：

服務端生成公鑰私鑰，下發公鑰給客戶端客戶端使用公鑰（還有鹽）對密碼加密把加密後的密碼傳送到服務端，服務端使用私鑰解密拿到密碼對於攻擊者來說，只要能夠拿到 HTTP 明文，就可以在公鑰下發時進行公鑰或者加密方式的替換，拿到密碼後解密，再使用伺服器公鑰加密密碼明文，返回給服務端。簡單幾步就可以拿到密碼明文了。從根本上說，就是說只要中間人能夠拿到 HTTP 明文，任何加密都是能夠破解的。然而客戶端 JS 加密的意義在於它提高了拿到密碼的成本。對於駭客來說，只要能監聽到網路的 HTTP，把所有的 HTTP 請求直接儲存到資料庫，然後定期進行資料清洗，就能直接拿到一大批沒有加密的密碼，用這種方式採集密碼，簡直就是用大網撈魚。如果客戶端採取了加密，「大網撈魚」的辦法就不奏效了。如果駭客需要拿到某個網站的使用者密碼，需要先分析加密方式，再針對性地代理和篡改 HTTP 內容，才能拿到密碼。加密之後，安全性提升了一個層次，可以把很多隻會用工具的「駭客」攔在門外，當然是有意義的。至於安全控制元件，因為它的加密演算法是寫在 native 裡面的，而且公鑰也可以直接內建到客戶端，中間人無法篡改公鑰，也就沒辦法拿到密碼明文。而且它除了加密，還起到了一些其他的作用。自然有理由認為它比 js 加密更安全。類似地，還有些網站全站 HTTP，只有登入部分用了 HTTPS，駭客完全可以在跳轉登入頁前進行劫持，把登入頁的 HTTPS 入口連結替換成 HTTP 並進行 HTTP 劫持。所以說這種安全防範就是掩耳盜鈴？在無法全站覆蓋 HTTPS 的情況下，登入頁能用 HTTPS 自然比不用好。再舉個相關的例子：HTTP 的網頁經常會被運營商篡改，插入一些廣告指令碼。在沒有能力進行 HTTPS 改造的情況下，有些網站會透過在響應頭中新增 CSP （Content-Security-Policy）來防範。從理論上說，這種防範方式是沒有作用的，因為運營商可以直接篡改你的 JS，更暴力的方式是刪掉 CSP 頭。但實際上，就目前來看 CSP 對於防運營商劫持還是有一定效果的。終極方案還是全站 HTTPS，然而它也不是絕對的安全，如果下面任一環節出問題的話：伺服器安全沒做好加密演算法和實現有漏洞，如 Heartbleed客戶端不安全，被安裝了木馬或者惡意外掛CA 不乾淨，或被安裝了私有 CA網頁存在 XSS 等問題