在瀏覽器端，安全控制項跟 JS 加密的密碼有何區別？

12-31

安全性都一樣么？如果用了同一個加密演算法的話

反對認為 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 等問題

這差不多是兩種完全不同的思路，下面我分三種情況來談。

首先是「在瀏覽器端通過 JavaScript 對密碼(或請求)進行 RSA 加密」，國內有些很知名的網站(據說人人和騰訊在用，但我沒具體調查)都在使用這種方法，但在我看來，這純粹是在造 SSL 的輪子，如果使用了 HTTPS 協議就沒有必要在客戶端對請求進行 RSA 加密了。而且造得並不圓滿——既然用於進行加密操作的 JavaScript 代碼是在不安全的信道上傳輸的，運算又是在客戶端進行的，並不能有效地防禦惡意行為。綜上這種方法最多能給攻擊者在理解網站工作原理上造成一點困難。

然後是「在瀏覽器端通過 JavaScript 對密碼進行散列」，即在註冊和登錄的時候都通過類似 MD5, SHA 之類的演算法對用戶的密碼進行一次散列。這種做法等價於強制用戶使用一個非常複雜的密碼，同時也避免了讓伺服器知道用戶的明文密碼(這是基於用戶的明文密碼屬於隱私這個假設的), 這種做法可以避免一些用戶使用弱密碼，同時可以保證伺服器在被攻擊者控制的情況下，攻擊者也得不到用戶的明文密碼。這種方法更適合一些小的網站和服務——因為這些小網站的安全措施往往更弱，所以要做最壞的打算。

最後是「安全控制項」，這種方案基於這樣一個假設：這個網站是絕對值得信任的(例如銀行), 以至於用戶可以容忍它在自己的電腦上安裝一個軟體(或瀏覽器插件), 而網站又認為用戶的設備是不值得信任的，可能會存在類似鍵盤記錄器一類的惡意軟體。相比於網頁，控制項有更高的許可權，可以對外界環境做出一些感知，可以一定程度上防禦一些安裝在用戶的計算機上的惡意軟體，大多數情況下安全控制項還會輔以上面的兩種措施。但我依然認為這種假設很沒有意義，如果用戶的設備已經被安裝上了惡意軟體，那麼就沒有什麼安全可言了。

綜上，我認為這三種方案都是「自作聰明」的做法，在特定場景下會起到一些積極的作用，但很有限。

哈哈哈哈哈這個問題我一定要回答而且不匿名

因為「JS加密」這件事情難道不是掩耳盜鈴嗎……而且我們這裡居然還真做了這麼一個項目括弧笑

咳咳

JS加密，1.演算法暴露（當然你可以說RSA, AES這樣的演算法本身就是公開的）2.密鑰暴露，這太致命了，密鑰本身就是通過網頁傳輸下來的。

所以，JS加密就是不僅給別人一把鑰匙，還附帶說明書（可能是鳥語寫的，JS混淆）描述了打開這鎖的方法。做人做到底，送佛送到西，我看差不多就說的這回事。

@王子亭提到的JS散列，這是可取的，這不是騙自己，因為對於很多自建賬號體系的小網站而言，存儲密碼就是用的散列，既然這樣，那在客戶端直接散列還能避免了明文傳輸。

但散列和加密是兩碼事呀，需要加密解密的場合，靠JS？開玩笑呢吧……

安全控制項這個我了解並不多，但我覺得這東西好賴也是個native程序，它自身的安全性和自我保護能力都比JS強多了。

拿到js加密的密碼，不需要太高的許可權，一個網頁用uxss就可以搞定，而要拿到控制項中的密碼，則需要system許可權。

所謂js加密的加密規則是暴露的，根本不算加密。

安全控制項有一定安全性，銀行不就在用么。

關鍵還是看協議演算法

從安全形度，js也好，控制項也好，都是可以被逆向分析的，這兩者的唯一區別，可能就是分析後者要麻煩點，但是因為每個客戶端控制項程序是一樣的，所以其實演算法也是可以分析得到的

如果考慮到中間人攻擊的情況，控制項要相對安全些，因為你不需要每次傳輸安裝控制項，但是js代碼在傳輸過程中存在被篡改的可能性

另外，有些控制項會偷偷給你機器的證書鏈加上自己的root ca, 這樣雖然保障了對方希望的安全性，但是對你自己的安全性卻無法保障，因為如果不是專業ca資質的公司，很難保證其ca私鑰的安全性, 這種情況下你的瀏覽器可是完全信任對方發布的證書的

如果某些情況下無法用https(比如買不起CA證書,客戶又不能接受你自己發行的CA證書), 那麼客戶端hashing演算法是必要的，但是因為一般密碼並不複雜，通過攔截hashing值來窮舉或者查彩虹表之類的是可行的，而且如果對方只是想通過認證，那麼直接發送hashing值即可，這種時候通過代碼模擬ssl過程+hashing過程也是可行的，可有效的防止對方暴力破，問題在於這種也是無法防止中間人攻擊的，要防止中間人最好ca

如果還要認證客戶端，就只能部署雙向認證（客戶端證書，ukey什麼的），這樣除非你的機器中毒，或者安全協議本身的bug,一般來說是安全的

總之，最基本的是必須hashing, 然後最好https + ca來保證信道安全和伺服器端的可信任性，如果是銀行等敏感行業，雙向認證則是必須的

看到一種寫法，把一個字元串，用charCodeAt（）然後再減去10000讓後再用fromCharCode()方法弄回來一個新字元，然後你們都是不認得吧。好吧然後告訴我這就是JS加密；我當時就無語了。

這裡我理解的安全性是這兩方面:

1. 防止密碼被客戶端抓取, 被第三方截獲,

2. 防止登錄token(非原始密碼)被客戶端抓取, 被第三方截獲, 從而利用非法登錄.

那麼區別還是有一些的, 安全控制項更勝一籌(不考慮用戶體驗的話 ).

個人認為, 安全控制項主要防止的是一些Keylogger(鍵盤記錄工具), 或者防止惡意Js注入. 在這方面, 不用安全控制項基本無能為力. 如果被keylogger, js注入, 那麼你的密碼在客戶端就丟了.

其次, 安全控制項可以一定程度上防止HTTP抓包/劫持, 因為通信這塊更容易防抓取, 防replay, 用JS我覺得也是可以的, 使用好秘鑰交換演算法, 也能保證一定程度的防嗅探.

至於隱藏加密方式, 這塊個人覺得是不那麼重要的, 因為加密方式背後, 主要的還是秘鑰, 如果秘鑰本身傳輸安全, 生成策略合理, 沒有泄漏, 演算法被人知道應該也沒太大關係(像一些用戶量大的工具, 登錄驗證相關的演算法應該被了解應該不難, 所以才有之前跑在Linux上的第三方QQ客戶端, 命令行版QQ).

可以從js源碼裡面把演算法剝離，用腳本控制項模擬加密，照樣還是能破解……而且上手並不難，不知道意義何在

這個最近也在研究，我對js登錄密碼加密的思路是這樣的：前端用js自編函數加密，後台傳隨機值session為鹽值，後台用session校驗，解密或不需解密，session在登錄成功驗證完成後銷毀，這樣中間人即使複製了加密後的密文也沒用，因為session已經無法校驗成功了。

另外因為js是可見的，所以js加密函數文件自身也要經過「函數變數名加密」而且看起來要足夠複雜，(這個工具在站長工具網站上有)讓人非常難以閱讀，原文件留備用但不公開。

用戶註冊時的密碼js加密我還沒想好，暫不評論。

安全控制項的話我的理解就是把本地的加密演算法封閉了，再加上一些本地的木馬檢測這些啰。這麼高要求的一般都只用在銀行網站上。