在《是時候放棄插件密碼管理器，改用密碼管理器插件了》一文中，我們談到密碼管理器插件的安全性不夠。
我們做了一個演示：將惡意JS代碼注入到Github一個無需登錄的網頁中，通過引誘用戶點擊關閉廣告，偷取用戶Github密碼。
Talk is cheap. Show me the video.
這個演示沒有利用任何瀏覽器漏洞。如果利用合適的漏洞，無需用戶點擊就能自動偷取密碼。
互聯網上絕大多數網頁都包含大量第三方內容，特別是廣告，很難保證所有內容都是安全的。一旦第三方內容含有惡意代碼，密碼管理器插件就可能存在泄密風險。
一、產品需求
神鎖離線版的用戶很早就強烈要求提供Windows版，將神鎖離線版的安全保護能力帶到Windows上。不過，桌面平臺沒有完善的沙盒保護，惡意軟件不僅可以讀取app存儲的數據，還能通過Keylogger或者掃描內存數據等方法偷取主密碼。而且，桌面平臺沒有普遍配置安全芯片，密鑰管理遠遠不如智能手機安全。
Independent Security Evaluators去年發佈的一份研究報告發現，桌面端密碼管理器可以通過掃描內存找到主密碼。《華盛頓郵報》報道相關事情並公開了一個演示視頻。
桌面端上常見的密碼管理器技術方案有兩種：
1.桌面客戶端
大約在十幾年前，PBKDF算法開始成熟，第二代密碼管理器允許用戶設置主密碼，將主密碼轉換爲密鑰來加密保護用戶的數據，這爲密碼管理帶來了真正的保護。直到今天，大多數密碼管理器仍然基於這一技術。
2.密碼管理器插件
桌面端軟件通常都可以記住密碼，輸入一次密碼後，用戶很少需要再次輸入。而運行在瀏覽器中的網站則經常需要用戶輸入密碼，所以在電腦端，用戶大多時候是在登錄網頁時會用到密碼管理器。
插件密碼管理器是基於瀏覽器插件技術實現的密碼管理器客戶端，通常與其他平臺客戶端保持雲端同步。它不僅具備桌面客戶端的主要功能，而且能輔助填充網頁中的密碼框，因此深受用戶喜愛。
不建議使用瀏覽器自帶的密碼管理器，它們大多屬於第一代密碼管理器——有管理，無保護。
我們經過深入調研後發現，這兩種技術方案在安全性上都不理想。因此沒有采用它們，而是獨創設計了掃碼遠程加密填充方案，讓用戶在電腦端瀏覽器上也能安全地填充密碼。
二、技術設計
1.不採用插件密碼管理器技術
大多數插件密碼管理器，都基於瀏覽器插件接口實現完整的客戶端，包括：用戶交互界面、自動填充、加密解密、密碼數據庫存儲和雲端同步數據庫等模塊。
除了桌面平臺本身缺少完善的沙盒保護和安全芯片等這些不足之處外，基於瀏覽器平臺的插件密碼管理器，還面臨更多嚴重的安全威脅：
- 主密碼泄漏風險
桌面客戶端可以採用一些系統底層技術，防止Keylogger程序偷取主密碼，但是基於Web技術的插件密碼管理器程序，無法訪問操作系統的底層接口，完全依賴瀏覽器的密碼輸入框，無法防範Keylogger攻擊。
- 瀏覽器漏洞
瀏覽器天然聯網的特性，讓很多漏洞更容易被黑客遠程利用。基於瀏覽器平臺的插件密碼管理器也很容易被攻擊。黑客不論是在操作系統上植入惡意程序，還是攻破瀏覽器的保護，都很容易破解插件密碼管理器。
- 瀏覽器插件技術暴露難以控制的攻擊面
安全研究員Martin Vigo曾在Even the LastPass Will be Stolen, Deal with It!中演示了破解LastPass插件的方法，其中基於插件客戶端的方法就有4種。
瀏覽器的插件開發接口基於Web技術，非常開放靈活。惡意程序通過 Web DOM/JS(Document Object Model/Javascript)，幾乎可以訪問和控制頁面中的任何內容。著名安全研究員 Sean Cassidy 在他的博文Browser Extension Password Managers Should Not Be Used中認爲無法避免插件密碼管理器的風險。
2.獨創的插件設計
設計邏輯
在研究技術方案過程中，我們逐步探索出這樣的設計邏輯：
- 基於瀏覽器的插件技術
瀏覽器插件可以方便解析必要信息，例如網頁中是否有登錄框、當前網址；幫助用戶自動填充密碼時，也可以使用DOM/JS技術，將用戶名和密碼填入文本框中。所以，基於插件技術才能更好地幫助用戶。
- 插件不管理用戶密碼
瀏覽器插件平臺在安全上的諸多風險難以克服，因此索性就不做密碼管理，直接將插件作爲神鎖離線版app在瀏覽器中的延伸。插件不管理也不保存用戶密碼，不暴露這個攻擊面，不給黑客留下攻擊的機會。
相當於基於插件技術實現一個遠程自動填充框架，而不是一個密碼管理器。
- 獲取填充信息
自動填充的原理是：先從網頁中獲取需要填充密碼的相關信息（網址等），再從神鎖離線版app中選擇對應賬號。App沒有網絡權限，不能訪問網絡，那如何將網頁中得到的信息傳輸到app中呢？我們沒有給神鎖離線版app增加網絡權限，而是改變了信息的傳輸方式：
a. 插件將網頁信息編碼成二維碼，展示在屏幕上
b. 神鎖離線版app掃碼獲取信息，無需使用網絡
- 填充
同樣，沒有網絡權限的神鎖離線版又怎樣將用戶所選的賬號密碼發送到插件呢？
是否可以使用電腦上的攝像頭掃碼手機app呢？使用電腦攝像頭掃碼雖然可行，但操作起來實在不方便。
智能手機都安裝有手機瀏覽器，可以通過瀏覽器運行雲端的H5網頁程序把數據發送到插件。發送的數據作爲H5網頁的參數輸入，H5網頁也能方便查看源代碼，用戶完全可以自行審計整個數據傳輸的安全性。
系統架構
《是時候放棄插件密碼管理器，改用密碼管理器插件了》一文介紹了插件的使用方法。其設計原理如下：
-
插件檢測到頁面登錄框後，生成橢圓曲線密鑰對(ECC密鑰對，elliptic-curve public–private key pair)，將公鑰和網址等信息編碼成二維碼，展示在頁面上。
-
用戶使用神鎖離線版app掃碼後，app會讓用戶選擇要填充的賬號。
- 用戶選擇賬號後，神鎖離線版app就會：
a. 生成ECC密鑰對
b. 使用ECDH算法生成共享密鑰
c. 使用共享密鑰加密用戶名、密碼等信息
-
神鎖離線版app啓動手機瀏覽器，將加密數據和ECC公鑰發送到插件
-
插件使用ECDH算法生成共享密鑰，解密得到用戶名和密碼
-
插件將用戶名和密碼填充到登錄框中
通過app端到插件端的ECDH密鑰協商，實現了端到端加密，確保用戶密碼不會由於雲端傳輸而被黑客甚至內部員工偷取。
使用神鎖離線版自動填充時，用戶需要在手機上操作兩次。和插件密碼管理器不同的是，桌面或者網頁中的惡意程序無法攻擊手機App。
3.插件程序組件介紹
插件架構
典型的Chrome瀏覽器插件有4大組件：
Background Script背景腳本負責處理事件和消息UI Elements包括插件icon上的popup，以及其他界面元素Content Script可以訪問網頁中的內容Options Page允許用戶設置一些選項參數等
每個組件都隔離在獨立的進程中運行，提升安全性。組件之間使用插件平臺提供的消息機制通信。
神鎖離線版插件的UI Elements和Options Page比較簡單，這就不討論了。Content Script和Background Script的工作原理如下：
Content Script
主要負責檢測頁面中的登錄框，以及將接收到的用戶名和密碼填充到登錄框中。它提供了兩方面的安全防護：
1.防欺詐
自動填充雖然方便，但也暴露了一個攻擊面，黑客可能利用自動填充偷取用戶密碼。今年的一篇論文Revisiting Security Vulnerabilities in Commercial Password Managers，重點研究了一些密碼管理器自動填充的防欺詐能力，發現它們普遍做得都不夠好。而神鎖離線版App的高級防欺詐能力可以有效防範這些欺詐。
神鎖離線版插件繼承了app已有的防欺詐能力，Content Script結合登錄頁面的信息，還提供了更多的欺詐檢測能力：
- 網頁使用了不安全的HTTP傳輸協議，填充和提交密碼可能會泄密
- 登錄域名與當前網頁域名不一致，填充和提交密碼也可能會泄密
爲什麼登錄域名應該與當前網頁域名一致？
互聯網平臺的賬號管理服務，內容一般比較精簡，不會包含第三方內容，執行更加嚴格的安全審計流程，甚至由專業的獨立團隊負責。
業務網頁以功能爲主，內容豐富，包含很多第三方資源，甚至大量第三方廣告。開發流程也不像賬號管理那樣嚴格，很難保證頁面中所有內容的安全，存在盜號風險。
2.防破解
目前來說，ECC算法是很安全的，暴力破解非常困難。而另一方面，量子計算已經顯示出未來破解ECC算法的潛力。無論是爲了防範哪種風險，都很有必要限制ECC密鑰的暴露時間，所以我們給二維碼設置了2分鐘的有效期，2分鐘後自動關閉掃碼框。神鎖離線版App再掃描2分鐘之前的二維碼，會提示過期，不會執行自動填充操作。
2分鐘時間一般夠用戶拿出手機掃碼填充，而無需手忙腳亂；即使將來量子計算破解ECC算法成熟了，預計也很難在2分鐘以內完成破解，傳統的計算機就更不可能破解了。
Background Script
負責密鑰管理和接收app發送過來的加密密碼，這是遠程自動填充框架的核心。因此我們做了很多的安全設計，包括：
- 密鑰管理後臺進程隔離
密鑰管理和雲端通信都在插件後臺進程中運行，與前端頁面完全隔離。
這意味着頁面中的惡意JS代碼無法通過DOM接口訪問到後臺進程中的加密數據。
- 請求限速
某些密碼管理器大量泄露用戶密碼的原因之一就是對數據請求沒有限制，惡意代碼可以模擬網頁登錄，偷取大量網站用戶的密碼。
爲此，我們設計了請求限速算法，限制創建密鑰對和二維碼的速度，直接拒絕明顯超出正常操作的請求。
- 高強度橢圓曲線密碼學算法
採用非對稱高強度橢圓曲線算法，協商加密密鑰，實現對填充數據的端到端（神鎖離線版app端到插件端）二次加密，即使是內部員工也無法偷看填充密碼。
通常可以選擇的ECC曲線有P-256、P-384、P-521等，兼顧安全性和兼容性，我們選擇了ECC P-384。
- 私鑰不可提取
const curve = {name: "ECDH", namedCurve: "P-384"};
page.keyPair = await window.crypto.subtle.generateKey(curve, false, ["deriveKey"]);
在調用WebcryptoAPI生成密鑰時，設置extractable參數 false，禁止提取私鑰。
惡意程序即使突破了瀏覽器的進程隔離，也仍然無法讀取不可導出的私鑰，除非它還能更進一步突破瀏覽器的密鑰管理保護。
- 一次一密
不存儲、不重用ECC密鑰對。不僅每個頁面會生成獨立的密鑰對，而且同一個頁面每次打開掃碼框都會重新生成。
結合Content Script的2分鐘二維碼有效期限制，極大提升了破解成本。黑客即使破解某次加密，也無法破解另一次填充。
插件接收到雲端發送過來的ECC公鑰和加密數據後，接下來：
- 協商加密密鑰
採用標準的ECDH算法，生成共享的AES-256-GCM密鑰。
const curve = {name: "ECDH", namedCurve: "P-384"};
const publicKey = await window.crypto.subtle.importKey('spki', keyBytes, curve, true, []);
const ecdh = {name: "ECDH", public: publicKey};
const aes = {name: "AES-GCM", length: 256};
const secretKey = await window.crypto.subtle.deriveKey(ecdh, page.keyPair.privateKey, aes, true, ["encrypt", "decrypt"]);
- 解密數據
解析出AES-256-GCM的IV(Initial Vector)參數和密文後，調用webcryptoAPI得到原文。
const ivBytes = Uint8Array.from(window.atob(encrypted.iv), c => c.charCodeAt(0)); const cipherBytes = Uint8Array.from(window.atob(encrypted.cipher), c => c.charCodeAt(0)); const aesParams = {name: "AES-GCM", iv: ivBytes}; const bytes = await window.crypto.subtle.decrypt(aesParams, secretKey, cipherBytes);
選用AES-256-GCM模式，在解密時還可以校驗數據是否被篡改過。相比AES-CBC等其他模式，進一步提升安全性。
當然，網絡通信必須全部採用HTTPS/WSS協議，再增加一層安全防護。
三、安全對比分析
大多數插件密碼管理器是一個完整的雲同步客戶端，神鎖離線版對瀏覽器的支持，拆解成了兩個協同工作的組件：
- 手機端神鎖離線版app：利用手機系統的安全特性（網絡權限、沙盒保護、安全芯片等）保護好用戶密碼
- 瀏覽器插件：充分利用瀏覽器提供的開發接口，實現遠程自動填充框架，確保通信數據安全並防止欺詐
將功能分解且分散在不同的終端，有效減小了攻擊面，能夠更有效地保護用戶數據安全。
攻擊面總體對比
| 攻擊面 | 神鎖離線版App | 神鎖離線版插件 | 插件密碼管理器 |
|---|---|---|---|
| 網絡 | N | Y | Y |
| 持久存儲 | Y | N | Y |
| 交互界面 | Y | Y | Y |
| Web DOM | N | Y | Y |
插件密碼管理器會暴露4個攻擊面，而神鎖離線版App會暴露2個，插件暴露3個。
神鎖離線版App和插件將兩個風險最大的攻擊面徹底分離——存儲數據不聯網、聯網不存儲數據。
那麼，相比插件密碼管理器，神鎖離線版插件在各個攻擊面上做了哪些改進呢？
1.網絡攻擊
-
網頁中的惡意代碼、惡意插件等，可能利用插件程序的安全漏洞來偷取用戶存儲的密碼。
-
服務商雲端。服務商內部“壞員工”，或者黑客入侵服務商雲端，都可能從雲端實施攻擊。比如在插件加載雲端網頁中的程序代碼時，植入惡意代碼，就可能偷取用戶輸入的主密碼/密鑰。而用戶數據庫早已同步到雲端，就缺這把鑰匙了。
神鎖離線版插件雖然也無法徹底杜絕惡意代碼、插件等偷取正在填充的密碼，但是不會泄漏所有密碼，因爲它們保存在更安全的手機系統中，不會受桌面端的影響。
2.持久存儲
Windows上運行的很多其他程序，都可以讀取Chrome瀏覽器的存儲數據，插件密碼管理器存儲的數據也在其中，包括加密的密碼數據庫，插件密碼管理器登錄服務的cookie，以及其他重要數據。
如果用戶選擇保存主密碼，惡意程序就可以解密出所有密碼。如果沒有保存，惡意程序需要的也僅僅剩一個主密碼了。雖然主密碼應該很長、很複雜、唯一，但很多用戶仍然會使用弱密碼作爲主密碼，仍然會重用主密碼，惡意程序還可以通過Keylogger技術偷取用戶輸入的主密碼。
當然，這還是比Chrome自帶的密碼管理器要安全很多，畢竟它連主密碼都不要。
神鎖離線版插件沒有暴露這個攻擊面。
3.交互界面
Sean Cassidy 在LostPass中展示了一項技術：利用像素級模仿密碼管理器界面，偷取用戶主密碼。
釣魚攻擊往往利用容易忽略或難以分辨的細節，誤導用戶將密碼輸入到惡意程序/網頁中。與瀏覽器集成度越高的插件，往往越容易被惡意程序釣魚。我們都知道，製作這種像素級完全一致的界面並沒有技術上的障礙。
瀏覽器沒有爲插件提供很多特別的界面支持，不能讓插件密碼管理器的界面顯得特別，不能幫助用戶分辨和防範針對密碼管理器的釣魚攻擊。這就尷尬了：
本來應該防範釣魚的密碼管理器，也可以被釣魚！
神鎖離線版插件和App一樣，沒有賬號，無需註冊，無需登錄，無需主密碼，無魚可釣。
4.Web DOM
這是瀏覽器插件獨有的攻擊面。開頭演示的視頻，就是利用瀏覽器的DOM編程接口，操縱了插件密碼管理器展示的界面，偷取了用戶密碼。如果可以利用合適的漏洞，甚至都不需要用戶操作，偷密碼於無形之中。
使用神鎖離線版插件填充密碼，需要用戶手動掃碼，所以用戶必然知道自己正在登錄網站。惡意程序不可能在用戶沒有意識的情況下，發動攻擊，自動偷取密碼。
其他安全增強
- 防欺詐能力
論文《Revisiting Security Vulnerabilities in Commercial Password Managers》中使用了多種欺詐方法攻擊多款流行的密碼管理器，沒有一款可以躲過所有的欺詐。
神鎖離線版插件增強的防欺詐，再結合App端的高級防欺詐，可以躲過一般欺詐。
- 權限要求
查看插件manifest.json，可以看到神鎖離線版插件要求的權限很少，不能讀取用戶瀏覽歷史記錄，不能監控網絡通信。所以，神鎖離線版插件既不能偷取用戶這些數據，也不會因爲被黑客攻破而泄露用戶隱私。
- 連接域名
同樣在manifest.json中，很多插件密碼管理器會聲明連接的服務域名，還有不受自己控制的第三方域名。服務商要確保很多個服務/域名的安全，甚至是第三方服務的安全，難度可以想像。
神鎖離線版不會連接第三方服務，也僅僅開放一個連接域名，相比要安全很多。
四、安全設計總結
神鎖離線版支持桌面瀏覽器，安全設計主要表現在這幾個方面：
密碼存儲
插件不保存任何用戶密碼，密碼仍然全部存儲在更安全的手機端app——採用了第四代安全存儲設計。
超過95%的安全事故都涉及網絡，神鎖離線版App仍然保持離線，沒有暴露這個最大的攻擊面，不受網絡相關攻擊的影響。
密碼傳輸
用戶在手機端選擇要填充的密碼，密碼被加密後傳輸到插件，插件解密密碼並填充到登錄框中。神鎖離線版插件採用了以下技術，確保傳輸的密碼安全：
- 密鑰管理後臺進程隔離
- 使用ECDH 高強度橢圓曲線密碼學算法，協商端到端密鑰
- 私鑰不可提取
- 一次一密
- 採用
AES-256-GCM高強度加密，且防數據篡改 - 底層通信採用 HTTPS/WSS
- 限制密鑰有效時間僅2分鐘
大家知道，HTTPS/TLS也廣泛採用ECDH/AES來確保數據安全，大多數密碼管理器雲端同步都會基於HTTPS/TLS。而神鎖離線版插件實現的ECDH/AES算法比HTTPS/TLS更安全，下一篇再做詳細對比分析。
防欺詐
神鎖離線版一向非常重視防欺詐能力，在插件上同樣延續了這個優良傳統，做了不少新嘗試：
- 需用戶手動掃碼
無法杜絕Web DOM的攻擊面，這給惡意程序留下了很多欺詐機會，但神鎖離線版app管理的密碼無論如何都不會憑空飛到桌面瀏覽器中。用戶手動掃碼這個操作，既讓用戶明確意識到密碼會發送到桌面瀏覽器，又限制了發送密碼的速度。程序可以每秒執行數百萬次，手動掃碼是不可能的。即使用戶不小心上當受騙，這個設計也有助於限制泄密的數量和速度。
-
請求限速
-
繼承App原來的高級防欺詐功能
在手機上選擇賬號填充時，App會清晰地展示當前正在填充的網址、是否需要填充密碼等信息。如果用戶選擇填充的賬號存在泄密風險，還會彈框提醒。例如，用戶打開了一個像素級復刻的釣魚網站faceb00k.com，在手機端選擇facebook賬號填充時，App就會提醒用戶這個是釣魚網站。
-
檢測網頁是否使用了不安全的HTTP傳輸協議
-
檢測登錄域名是否與當前網頁域名不一致
特別指出：通過插件填充密碼，無法避免密碼被惡意插件或者網頁中的惡意JS腳本通過網頁DOM讀取。對此，技術上還沒有辦法杜絕，即使是用戶手動輸入密碼，也同樣無法避免。