基于B/S 模式的信息化密碼管理系統的設計與應用

李大同 陳昱希 張展飛 張文杰 廖南嬌

引言

現如今，隨著計算機技術的迅速發展，各類應用系統已廣泛在企業的日常工作中使用，為企業辦公自動化提供了很大的幫助，但同時也帶來了諸多問題。隨著信息管理系統數量的增加，不同的管理系統的登錄模式、數據結構、體系架構和功能模塊之間也有了很大的差異。由于上述的差異化，各個系統之間使用的登錄方式有可能不同，但是使用多點登錄的方式可能會導致各種各樣的信息安全問題。為了解決這樣的信息安全等問題，降低不同用戶在運維過程中的復雜程度，打破不同信息系統之間的隔閡，建立企業的信息化應用平臺，以此來提高開發效率，降低運維難度。

經過市場調研，許多企業對公共服務需要共享其賬號密碼是有比較大的需求的；首先是企業宣傳運營管理部有很多媒體賬號需要安全有序管理，比如公眾號，官微賬號，企業應用市場賬號等；其次是企業HR也有很多招聘網站的賬號密碼需要管理；最后是企業各種內部管理工具，SaaS服務賬號等。所以賬號密碼作為公司的重要虛擬資產，需要一個行之有效的管理方法，安全、精細管理。眾所周知，當前所有企業基本都在進行企業管理信息化建設，那么針對其建設過程中面臨的應用系統集成、用戶身份管理等問題，本系統的開發可以實現信息系統統一、高效、安全的用戶身份管理，以便于新應用系統的集成[1]。

一、系統架構

（一）技術架構

系統采用微服務部署，通過使用Docker容器來承載不同的業務，并且在網絡層與系統層都部署了負載均衡的設備及應用，確保系統高可用的同時，當發生非法入侵時方便數字取證，且在后續的硬件或操作系統升級時，方便系統的遷移。具體如架構如圖1所示。

圖1 系統總體架構

（二）數據加密

需要考慮三種數據狀態：

(1)傳輸中的數據；

(2)使用中的數據，即在服務器或客戶端的內存或文件系統中的數據；

(3)靜態數據，即電源關閉時在文件系統中的數據。

對于使用中的數據，只有密碼會被加密。例如，用戶名、評論或與共享密碼的人員列表未使用OpenPGP加密，并以明文形式存儲在客戶端和服務器端。顯然，密碼在某些時候可以通過解密形式獲得（越晚越好），但它們永遠不會以明文形式存儲在客戶端或服務器端的文件系統中。

對于傳輸中的數據，例如在傳輸層級別，所有通信都使用SSL加密。該級別的安全強度不受本項目的密碼管理平臺解決方案本身的控制，而是由其他因素的組合控制，例如頒發證書的組織的安全級別和托管提供商選擇的操作系統配置。

對于靜態數據，在大多數客戶端和服務器中，也可以在文件系統級別加密數據庫，這將添加另一個有用的加密層。

二、底層架構及原理

（一）密碼中的身份驗證

本項目的密碼管理平臺不是經典的基于表單的身份驗證，而是基于設置期間設置的OpenPGP密鑰執行以及基于質詢的身份驗證。本章節的目的是幫助解釋此身份驗證過程如何工作以促進審查和討論以及未來與其他產品的集成。授權技術多為基于訪問控制模型和授權協議進行設計[1]。本項目的目標是提高整體解決方案的安全性和可用性，例如，重用本項目的密碼管理平臺的現有OpenPGP設施以避免讓用戶記住另一個密碼而不是他們的密碼。

1.基于表單的身份驗證

雖然現在一些Web應用程序遵從其他服務（例如騰訊SSO及短信驗證碼）來處理身份驗證，但大多數仍然默認支持基于表單的身份驗證。在注冊期間，密碼被發送（最好通過HTTPS）到服務器。然后使用crypt（或等效）對該密碼進行加鹽和散列處理，并存儲以供服務器進一步使用。只有此應用程序實例知道的鹽用于防止密碼的哈希值泄露（例如通過SQL注入）的暴力破解[3]。

在以與設置類似的方式發送登錄期間，服務器對其進行哈希處理并將其與存儲的版本進行比較。如果它們與服務器存儲一個會話令牌，該令牌作為cookie（或URL參數）發送回并在客戶端設置。此cookie由客戶端在會話期間為每個請求生成（直到cookie過期、用戶注銷或服務器終止會話）。

2.基于表單的方法的問題

主要問題是可用性。將這種方法用于本項目的密碼管理平臺意味著用戶需要在其私鑰密碼之上記住另一個密碼。這抵消了擁有密碼管理器的好處。

本項目還將密碼存儲在身份驗證插件中，但這會使要求復雜化，因為它會引入本項目的密碼管理平臺用戶賬戶密碼創建、更新和恢復的需要。

另一個大問題是用戶無法使用電子郵件驗證重置密碼，以防電子郵件客戶端的密碼存儲在本項目的密碼管理平臺中。

其他問題不是本項目的密碼管理平臺特有的，但仍然值得嘗試使用另一種方法來解決：比如網絡釣魚，密碼質量等。

3.基于GPGAuth的身份驗證

這個過程將遵循GPGAuth協議。該過程通過用戶和服務之間加密和簽名令牌的雙向交換來工作。認證過程如圖2所示：

圖2 基于GPGAuth身份驗證

4.驗證步驟

（1）客戶端生成隨機數據的加密令牌（使用服務器公鑰加密），并將未加密版本存儲在本地。

（2）該加密令牌與用戶密鑰指紋一起發送到服務器。

（3）服務器根據用戶密鑰指紋檢查用戶是否存在以及是否處于活動狀態。如果是這種情況，服務器將解密nonce并檢查其格式是否有效。

（4）服務器發回解密后的隨機數。

（5）客戶端檢查隨機數是否與先前記錄的隨機數匹配。如果不匹配，客戶端會警告用戶無法驗證服務器身份。

5.登錄步驟

（1）用戶發送他們的密鑰指紋。

（2）服務器檢查指紋和關聯的用戶是否有效。然后它生成隨機數據的加密令牌，并將未加密版本存儲在本地。

（3）服務器將未加密的簽名用戶令牌和加密的服務器令牌發送給用戶。

（4）用戶輸入他們的私鑰密碼，客戶端解密隨機數并檢查令牌格式。

（5）客戶端將解密后的隨機數與用戶密鑰指紋一起發回。

（6）服務器比較從客戶端發送的未加密的簽名令牌以確保它匹配。如果服務器滿意，則與基于普通表單的登錄一樣完成身份驗證：啟動會話。

6.注釋和備注

根據協議定義，服務器密鑰驗證步驟是可選的，但建議所有的客戶端默認執行它。

在未來可能會嘗試減少HTTP請求的數量：例如，目前不能在驗證步驟中請求nonce1。因此，對于驗證步驟，總共需要3個POST。整個協議可能會簡化為單個GET/POST往返，例如基于表單的身份驗證。

還有一個可選的“步驟0”，用戶在其中執行GET/auth/verify請求。這可以用來獲取服務器公鑰和服務器驗證的URL，或者查看服務器發布的公鑰。

7.GPGAuth優點

除了不必記住額外密碼的可用性優勢之外，本項目還提供以下額外優勢：

網絡釣魚：由于客戶端不輸入密碼，因此降低了這種風險，例如，僅獲取密鑰密碼將不允許攻擊者登錄。由于客戶端可以根據服務器密鑰（手動添加到密鑰環）驗證服務器身份，因此攻擊者僅偽造表單和域是不夠的。

密碼質量：身份驗證令牌的強度比經典密碼強，因為每次也使用不同的“密碼”，并且與私鑰主密碼的復雜性無關。

8.殘留風險和缺點

目前的解決方案仍然存在風險：

服務器：客戶端公鑰有效性的完整性和驗證。服務器可能會被誘騙存儲錯誤的客戶端公鑰。為防止這種情況，服務器必須通過OpenPGP信任網絡自動檢查有效性和/或通過檢查公鑰服務器和/或必須由管理員進行手動檢查。

由于加密/簽名操作比基于“正常”表單的登錄中的密碼哈希操作成本更高，因此這些端點可能會被用來創建拒絕服務。為了降低這種風險，系統限制了嘗試，例如隨著時間的推移限制嘗試的次數。

有關用戶群的信息泄露。攻擊者可以通過請求加密的隨機數并收到錯誤來查明用戶是否在服務器上擁有賬戶。在標頭中泄露信息以提高可用性并提供更好的錯誤消息：例如，告訴用戶其賬戶已被刪除。

服務器公鑰的完整性和驗證。客戶端可能會被誘騙存儲無效的服務器密鑰。為防止這種情況，客戶端必須在設置期間檢查有效性（如前例）。同樣，在設置期間，客戶端還必須檢查域/密鑰映射，以防有人使用虛假但非常相似的域URL創建真實密鑰。目前已實施，但肯定可以改進，因為最終用戶仍然可能犯錯誤并且無法正確檢查。

客戶端/服務器可能被誘騙解密并返回/簽署錯誤數據，例如攻擊者先前捕獲的電子郵件。為了緩解這種情況，加密格式消息是固定的（例如UUID）并由服務器簽名。如果SSL可以破解，身份驗證cookie就可以被竊取。這并非特定于此身份驗證方法，因為表單身份驗證也容易受到此類攻擊。此外是沒有替換和撤銷密鑰的工具。

（二）角色和權限

1、系統角色

本項目的密碼管理平臺提出了兩個系統角色管理員和用戶。該系統是授權機制的第一線，直接對每個用戶的操作執行檢查。

簡而言之，管理員管理實例。實際上，這意味著他們可以管理組織范圍內的設置，例如電子郵件通知的內容或啟用了哪個多因素身份驗證提供程序。另一個職責是創建或刪除用戶、管理組和組管理員、執行與用戶目錄的同步等。

2、組級角色

每個群必須至少有一個群管理員負責添加和刪除群成員。管理員可以指定自己為組管理員或指定普通用戶，具體關系如圖3所示。

圖3 角色關系

由于本項目的密碼管理平臺中加密的性質，只有有權訪問給定組的秘密的人才能將成員添加到該組（因為他們需要能夠為新成員解密和加密密碼）。

3、資源級角色

本項目的密碼管理平臺在資源層面提供三種權限：

（1）所有者：可以管理共享設置、刪除、更新、讀取。

（2）更新：可以更新記錄和刪除。

（3）讀取：只能讀取和使用密碼元數據和秘密。

4、文件夾級別角色

在系統底層，文件夾權限將重用于資源可用權限系統相同的權限系統。這將允許用戶將一組權限關聯到一個或多個文件夾。與資源一樣，文件夾必須具有在文件夾權限中定義的所有者權限。還有兩種其他權限類型可用：更新和讀取。

一旦項目位于文件夾中，可以對項目執行的操作不取決于文件夾權限，而是項目本身，就像在常規文件系統上一樣。對于要移動文件夾內的項目的用戶，他們通常必須至少具有對該項目和目標文件夾的更新權限。

三、應用工作原理

（一）系統接口

密碼服務器組件API 以 REST 方式在 HTTPS 上工作，因此它與語言框架無關。可以使用適合的工具集將密碼管理服務集成到現有的工作流程中[2]。要開始使用密碼管理 REST API（以下簡稱“API”），至少需要：

（1）一個正在運行的密碼服務器實例。

（2）如果您想訪問受保護的數據，請使用密碼用戶帳戶。

（3）對公鑰加密的工作原理有一些基本的了解。

（4）用于構建的OpenPGP 兼容庫。

API 通過 HTTPS 提供。本文中引用的所有 URL 都省略了密碼安裝域的基本 URL，例如：https://.

（二）響應包結構

API 在具有“header”和“body”屬性的信封中返回數據。“header”包含響應元數據，如響應代碼、server_time、錯誤消息等。“body”包含實際有效負載。

（三）錯誤響應

不成功的操作將導致錯誤響應。錯誤響應將遵循與上面相同的方案，同時存在“header”和“body”屬性，只是這次標題中的狀態將設置為 error而不是success。響應正文將包含錯誤詳細信息。

如上所示，對于驗證錯誤，響應正文包含兩個鍵，“name”和“secrets”，因為它們未通過某些驗證規則。此外，它們還有自己的 json 對象，其中包含一個表示失敗的驗證規則的鍵（“_required”）和一個包含實際錯誤消息的值（“A name is required”）。

（四）訪問密碼服務器公鑰

在身份驗證的“驗證”步驟中需要密碼管理服務器公鑰。此步驟允許客戶端驗證服務器身份，例如防止域被占用等不太可能的情況。密碼管理服務器在/auth/verify.json 廣播其公鑰：

結語

構建具備高可靠性的統一身份認證體系，對于復雜商用環境特別是金融業業務系統大集中的場景下意義重大。隨著軟件開發技術的不斷發展，目前各大企業均構建了面向不同業務領域的系統，企業中多項目的團隊尤其是初期階段會嘗試很多系統，人員流動也比較大，要有效地管理好賬號密碼，在新員工入職時可以迅速發放，員工離職時可以快速收回，并且在密碼使用過程中盡可能保障安全，線上服務器密碼管理也是比較重要的一環。目前，該系統已經在本市的某企業部署應用，并且取得了良好的應用效果，大幅提升了運維人員的運維效率，實現了對企業數字資產的統一控制。