兩分鐘實現安全完備的登陸模塊

引言

2016年中，我所在的項目組將原來系統中的登陸模塊拆出來作成一套集中帳號管理系統，並對外提供單點登陸的服務。後來，公司中須要使用員工帳號進行登陸的系統愈來愈多，但這些系統都是各有各的實現方式，管理比較混亂。爲了推廣咱們組的帳號管理系統，統一公司的帳號體系，我寫了一篇「軟文」但願在公司技術月刊上發表，即是這篇文章的來歷。

隨着公司業務的不斷髮展，各類內部管理系統也愈來愈多，這些系統雖然功能職責各不相同，但有一個功能模塊是全部這些系統都必備的，那就是登陸模塊。登陸模塊負責生成並存儲識別用戶身份的數據，在有用戶對系統進行操做的時候驗明用戶的真實身份，並進行適當的權限限制。

如何實現登陸模塊

要實現一個基礎的登陸模塊很是簡單，大概有下面幾個步驟：

 

1. 實現用戶註冊頁面，用戶填寫包括用戶名密碼的基本信息以後，將用戶信息存儲到數據庫。
2. 用戶嘗試對系統進行操做前，判斷用戶是否登陸，若是沒有就跳轉到登陸頁面讓用戶輸入用戶名密碼。
3. 用戶輸入正確的用戶名密碼以後，驗明用戶身份並生成 session 和 cookie，以便在用戶作下一次操做時判斷用戶的身份和權限。

完成上述三個步驟，一個基本的用戶登陸模塊就完成了。可是，凡事總有可是，事情並無這麼簡單。在一個真實的場景中，做爲系統信息安全的重要保障，登陸模塊每每還須要考慮不少的實現細節。

1. 弱口令限制

   不少用戶在註冊的時候，喜歡使用很是簡單的密碼，好比 123456 或者 qweasd 之類的。尤爲在企業內部系統中，這種用戶密碼更是常見。可是，這類密碼簡直形同虛設，如此簡單的用戶密碼，很是容易被惡意用戶猜解，從而致使信息的泄露，對企業信息安全形成嚴重威脅。爲了不這種狀況的發生，咱們在新用戶註冊或用戶重設密碼的時候，每每會對用戶密碼複雜度作出必定的限制，好比要求用戶密碼必須同時包含數字、大寫字母、小寫字母、特殊符號四類字符中的至少三類，且密碼位數不能低於8位。

2. 註冊驗證

   做爲一個企業內部系統，咱們每每不但願企業外部人員也可以註冊成爲用戶，由於這極可能會致使企業內部信息的泄露。那麼，如何保證外部人員沒法註冊呢？常見的手段是使用企業郵箱對註冊人的身份進行驗證。好比，用戶在註冊時，除了要用戶輸入用戶名和密碼之外，還須要用戶輸入其企業郵箱帳號。用戶提交註冊表單後，系統驗證其輸入的郵箱帳號是企業內部的合法郵箱帳號，並向這個郵箱發一封註冊驗證郵件，其內包含一個隨機生成的複雜連接，用戶點擊這個連接以後，才能徹底註冊成功。

3. 加密存儲密碼

   用戶註冊成功以後，系統須要將用戶名和密碼的相關信息寫入數據庫或相似介質，以便用戶下次登陸系統時查詢驗證。但是爲了防備一些很是規的狀況，咱們每每不能直接明文存儲用戶的密碼，而是用摘要算法對用戶密碼進行若干處理，再將摘要信息寫入數據庫中。好比，用戶的原始密碼是 hell0W0rld ,咱們先用 MD5 算法對密碼作摘要，獲得摘要密文 17529cb075a386f08409f260bf0dfb8c ，而後再用用戶的註冊時間戳做爲 salt 拼接到密文上，獲得 17529cb075a386f08409f260bf0dfb8c1484547629852 ，再對這個字符串用 MD5 算法作摘要，獲得密碼摘要信息 6ee203a6a6c05a6f8f958c5be00b1313 ，最後咱們將用戶名、密碼摘要信息、用戶註冊時間戳三個信息所有寫入數據庫中，以便未來驗證用戶身份。

   這樣的作法雖然看起來比較繁瑣，但其安全性獲得了比較高的保障。即便數據庫中的密碼信息被徹底盜取，且用戶的原始密碼相對簡單，面對加了隨機salt且作過兩次摘要的密碼信息，想要猜解出原始密碼也是很是困難的

4. 驗證碼

   暴力猜解是比較常見的用戶信息猜解手段，簡單點說，就是用程序反覆嘗試用不一樣的密碼登陸某個帳戶，直到成功爲止。這種破解用戶密碼的方式，一方面增長了用戶信息泄露的風險，另外一方面也因爲系統須要不斷的查詢數據庫驗證密碼正確性，而大大增長了系統的資源消耗。爲了防止這種狀況，通常咱們須要經過隨機圖片驗證碼來驗證當前提交登陸請求的是人而不是某種程序。而通常爲了平衡用戶體驗和系統安全性兩方面的要求，常見的作法是用戶輸錯密碼3次後再要求用戶輸入驗證碼。

5. 失敗次數

   雖然咱們加了圖片驗證碼提升系統的安全性，但仍是有一些比較高級的破解程序，能夠正確識別出圖片驗證碼的內容。因此，咱們還須要加上嘗試失敗次數的限制，當用戶嘗試登陸失敗超過指定的次數以後，系統就會鎖定該帳號。一段時間內，不管用戶是否輸入正確的用戶密碼，系統都拒絕該帳號的登陸請求，必須找系統管理員手段解鎖，或等待一段時間以後才能再次嘗試。

6. 找回密碼

   找回密碼也是很常見的需求點。用戶有時候真的會忘記本身的密碼，這時，須要用戶可以手動重置本身的密碼。常見的作法是用戶提交重置密碼請求，系統向該用戶的註冊郵箱發一封密碼重置郵件，內含一個隨機生成的複雜連接，用戶經過這個連接地址訪問系統的密碼重置頁面來重置本身的密碼。

7. HTTPS

   用戶在發起登陸請求時，輸入的帳號和密碼信息經過網絡發往服務器，這些信息在發往服務器的過程當中會經歷很是多的網絡節點，若是信息在傳輸過程當中是明文狀態，那麼這些網絡節點就均可以獲取到用戶的帳號和密碼信息，這將成爲很是大的系統信息安全隱患。所以，對用戶登陸過程當中的敏感信息進行加密傳輸是很是必要的。最多見的作法就是對登陸請求用 HTTPS 協議代替 HTTP 協議。

8. 跨平臺特性

   不少的系統都具備跨平臺特性，好比 OA 系統，咱們能夠在 PC 上填寫加班申請單，在手機瀏覽器上查看這個申請單的審批狀態，而若是公司員工是在微信中訪問 OA 系統的頁面，OA 系統還會經過關聯的微信帳號讓用戶直接登陸系統，免去了輸入用戶名密碼的步驟，從而大大提升了用戶操做的便利性。

由此咱們能夠看出，要實現一個功能完備又安全的登陸模塊，並非一件很是簡單的事情，這其中設計、開發、測試的工做都須要花費大量的時間和人力，那麼咱們又怎麼能在兩分鐘內爲各應用系統實現這麼多複雜的功能呢？答案就是使用 UserCenter。

如何使用 UserCenter

UserCenter 是 OA 組根據公司實際業務場景設計實現的單點登陸系統，功能完善，可靠性高，使用方便。

使用 UserCenter 只需簡單的兩個步驟：

1. 安裝 UserCenter SDK

   UserCenter 經過 Composer 包分發其 SDK，只要在項目的 Composer 配置中聲明依賴 UserCenter 就能夠了。
   

2. 修改 Controller 基類的 _initialize 方法，調用 UserCenter 的接口
   
   複製上面的代碼到 Controller 基類中，修改第 4 行和第 15 行的代碼便可。

UserCenter 的其餘優點

UserCenter 系統不只功能完備安全性高，可靠性也值得信賴。目前系統採用主從備份部署方式，武漢和深圳機房各有一套服務處於運行狀態。員工帳號數據可以實時在主從服務間進行同步，一旦主服務因網絡或電力故障沒法訪問，系統會將登陸和身份驗證的相關網絡請求切換到備用服務上，使得各應用系統的用戶登陸功能不受影響。

同時，UserCenter 還支持各類第三方系統經過 LDAP 接口接入，如公司正在使用 PMS、WIKI 以及 JENKINS 系統等等。

另外，使用 UserCenter 以後，公司各內部系統共用同一套帳號系統，在新員工入職和老員工離職時，帳號的建立和回收工做都將更加便利和安全。同時，因爲使用 UserCenter 的各個應用系統再也不須要單獨保存用戶的帳號和密碼信息，使得公司員工帳號泄露的風險大大下降。

結語

目前，公司尚未統一的的身份驗證策略和框架。隨着業務的增加和時間的推移，這將致使大量內部系統都擁有一套本身的身份驗證模塊和用戶帳號數據。每一個員工都須要記住多個用戶名和密碼，才能訪問各個不一樣的系統。這給系統管理人員以及公司的各個員工都帶來很大的負擔。若是沒有統一的策略，開發人員就須要爲每一個系統重複實現定製的登陸模塊，這還會致使各類維護上的麻煩問題。UserCenter 爲安全性和身份驗證提供了統一的範式，大大減輕了用戶、管理員和開發人員的負擔。

 

如需轉載，請註明轉自：http://www.cnblogs.com/silenttiger/p/6296315.html

 

歡迎關注個人微信公衆號：老虎的小窩