密碼代填是一種幫助使用者實現自動登入的方式，它透過自動模擬使用者填寫賬號密碼的方式來進行登入，嚴格來說它不屬於單點登入範疇，由於國內不少企業採用這種方式來登入日常應用，所以也成為了一種廣泛應用的實現單點登入的形式。有人說密碼代填很落後，有人說它有特定的應用的場景，那麼“密碼代填”到底安全嗎？是否值得采用？本文就來深入探討一下。
一、“密碼代填”的幾種常見方式
“密碼代填”顧名思義就是程式代替使用者填寫登入資訊表單，實現自動登入的過程。主要有以下幾種實現方式。
1. 透過應用提供的介面獲取賬號密碼
某些應用提供了特定的登陸介面，讓第三方呼叫並傳遞使用者名稱密碼，然後就能實現登陸。即，在原本的登陸頁面之外，額外提供了一個介面傳遞賬號密碼實現登陸。
這種方式下密碼資訊會直接透過網路傳輸，安全性完全無法保證，這種方式非常原始，不提倡。
2. 透過POST介面直接提交表單
第二種方式是當用戶點選應用時，身份認證服務提供商（IAM or IDaaS） 執行一段javascript指令碼，直接呼叫應用的登陸介面，並將賬號密碼資訊，透過POST表單提交的方式，直接嚮應用傳遞，直接登入應用。在整個的流程裡，伺服器透過執行一段javascript指令碼，直接傳輸賬號密碼，是不會開啟應用登入頁面的。
這種方式實現起來最為簡單，本質上可以理解為機器繞過了瀏覽器登陸頁面，直接登陸了使用者身份。
但隨著大眾網路安全意識的不斷提高，現在越來越多的網站開始透過各種方式遮蔽機器直接登陸。其中最為常見的一種方法就是在登陸頁面載入的時候
新增隨機Token
——在登陸表單提交的時候，除了必要的身份資訊，還需要攜帶此隨機Token，防止機器直接提交賬號密碼獲取使用者身份，如下圖所示，
像 Github這樣的應用就無法使用這種方式登入：
3. 透過瀏覽器外掛提交表單
第三種方式是 IAM 提供瀏覽器外掛，與第二種方式“直接呼叫 Login 介面”不同，
瀏覽器外掛會完全模擬使用者手動的登入操作，可以分解為三個步驟：
第一步，使用者自主開啟應用登入頁面；
第二步，瀏覽器外掛自動工作，自動填寫賬號密碼錶單；
第三步，瀏覽器外掛自動點選登入按鈕。
這種方式的優勢在於模擬了整個的使用者行為，能夠適用於絕大多數的網頁端應用，包括上文的 GitHub，外掛先開啟應用頁面時就獲取 Access Token等登入引數。
它的劣勢在於外掛開發和維護成本比較大。
當應用的登入頁 UI 改變時，需要及時更新外掛的引數（表單位置、登入按鈕位置等），並且需要企業所有使用者在 IE、Chrome、Safari 等瀏覽器中自助安裝對應的外掛。而在不支援安裝瀏覽器外掛的移動端，也無法用這種方式實現密碼代填。
二、密碼代填是否值得采用？
總的來說，以上三種密碼代填方式都需要先將終端使用者的賬號密碼儲存在身份認證服務商（IAM）的伺服器中，
使用者登入過程中不可避免地傳遞賬號密碼，安全性較差
。這也是為什麼越來越多的應用開啟了二次認證（比如簡訊驗證碼、滑塊驗證等形式）來阻止密碼代填操作。
然而在實際應用場景中，「密碼代填是否值得采用」，這一問題並不能“一刀切”下結論，這完全取決於企業應用場景的限制和安全性要求。
一般情況下，我們推薦企業選擇標準SSO協議的方式進行單點登入。在可以使用SSO的場景下，SSO是絕對優於賬號密碼的登入方式的。
但並不意味著所有的場景都能夠使用SSO。據統計市面上絕大部分的ToC的應用都是不支援SSO
，比如大家平時使用的各種部落格、貼吧、網盤等網站，由於是面向個人使用者的，一般只會支援賬號密碼登陸，不會支援標準SSO協議；還有很多企業內部自研的內部系統，一般是服務於具體業務，不需要對外網開放，一般不會專門預留工期用於SSO的適配。在這些場景下，密碼代填的方式能夠幫助客戶記住賬號密碼，實現快速登入。
如果企業由於各種客觀條件限制，只能選擇使用不夠安全的密碼代填，那麼就需要採用足夠安全的金鑰管理服務（Key Management Service，簡稱KMS），來保證生成和管理非對稱加密的公私鑰的過程，以及加密儲存敏感資訊的安全性。
玉符基於零信任安全模型對KMS服務進行了精心設計，可以幫助企業更好的保護這些敏感資訊，包括但不限於以下措施：
對每個敏感資訊獨立加密儲存，在每個敏感資訊建立的時候，KMS會自動分配一個新的256 bits對稱加密用金鑰，保證即使未來單個資訊被攻破也不會影響其他資訊。
使用最新的密碼學規範（例如RSA-256），並保持更新，支援金鑰輪轉；
所有私鑰永遠不會明文暴露在外部服務或持久化儲存（例如資料庫）；即使網路資料被監聽攔截、資料庫被竊取，駭客也無法獲取私鑰資訊。
有價值的敏感資訊也只會在服務執行時快取在受保護的記憶體空間內（安全界限範圍Security Barrier），不會存在於伺服器的硬碟上（全面禁用SWAP虛擬記憶體）。即使駭客攻破伺服器的檔案系統（filesystem）也無法獲得有用資訊。
整個KMS服務的啟用基於Shamir’s Secret Sharing演算法，受5個主令牌（Master Tokens）保護，每次必須有3個或以上的令牌同時輸入才能啟用（unseal）服務。即使整個伺服器的內容被偷竊，偷竊者也無法成功啟動KMS服務來獲取資料。
加入防篡改機制，服務執行過程中會對所有加密資料的完整性進行檢測。一旦有駭客對底層加密資料有任何修改都會導致程序自動封鎖。
……
三、安全性更高的單點登入實現方案
再來解釋一下 SSO 協議在安全性上的具體優勢。標準的SSO協議有很多，像基於XML的SAML協議，在OAuth2。0上的身份驗證層OpenID Connect協議等等，它們都是透過受信伺服器和應用伺服器之間的Token互動實現的，其中運用了密碼學的演算法知識，從而保證整個登入行為的安全性（關於單點登入中的Token認證可以參考這篇文章
《IDaaS技術解析 | 單點登入 Token 認證》
）。
與密碼代填相比，透過標準SSO協議實現單點登入，不需要知道使用者的實際密碼，只需要知道需要登入的賬號名即可，從根本上避免了密碼洩露的風險
。而使用者也無需再透過複雜的密碼策略來保證賬號的安全，甚至使用者本身都不需要知道應用系統的密碼，再也沒有了忘記密碼的煩惱。
引入標準的SSO協議的另一大好處在於，員工的登陸行為可管控。
企業IT管理員可以檢視到使用者在什麼時間什麼地點登陸了什麼應用，結合風控報警體系後，可以有效杜絕不正常的登陸行為，保護企業賬戶安全。
四、小結
綜上，密碼代填雖然在安全性上不夠穩妥，但是在特定的應用場景下依然是最便捷的單點登入的實現方式，也建議企業使用更加可靠的 KMS 服務減少敏感資訊洩露的風險。
當然，為了長遠的系統安全考慮，只要條件允許，我們建議企業使用安全性更高的標準 SSO 協議對接的方式實現單點登入。
