如何設計安全的用戶登陸功能

用戶登陸功能是Web應用系統具有的最基本的功能，關係到用戶數據和應用系統數據的安全，設計一個安全的用戶登陸功能，涉及到如下幾個方面的內容。
(一) 老生常談——口令
1. 口令長度與複雜度限制
限制用戶輸入一些很是容易被破解的口令，好比qwert、asdfg、12345六、password之類的，參考twitter和 facebook的設計，爲這樣的口令作一個黑名單，不容許使用黑名單中的口令。同時，還對用戶口令的長度、複雜度進行檢查，要求用戶設置足夠長度，且復 雜度符合安全策略的口令。
在口令安全的這個方面，用戶體驗和安全多是相對的。限制用戶輸入某些口令及口令的長度和複雜度，在用戶體驗方面可能並不太好。因此，不少成功且 設計良好的社交網站（SNS）都提供了UX讓用戶知道他的口令強度是什麼樣的，這樣可讓用戶有一個選擇，目的就是告訴用戶——要想安全，先把口令設得好 一點。
2. 不要明文保存用戶的口令
用戶都會用相同的ID相同的口令來登陸不少網站。因此，若是Web應用系統明文保存口令的話，那麼，數據被不良員工流傳出去那對用戶將是災難性的。因此，用戶的口令必定要加密保存，最好是用不可逆的加密，但不要直接使用諸如MD5或是SHA1之類加密算法。
3. 不要讓瀏覽器保存口令
瀏覽器記住口令，對用戶來講是很方便的事，由於用戶不可能記住那麼多的口令，只能藉助於某些工具幫助記憶，瀏覽器只是其中的一種。但對於用戶數據的安全來講，有不少方法能夠獲取瀏覽器記住的口令。因此，不要讓瀏覽器保存用戶名和口令。
(二) 用戶登陸狀態
HTTP是無狀態的協議，是沒法記錄用戶訪問狀態的。用戶的每次請求都是獨立的無關聯的，一筆是一筆。而咱們的Web應用系統都是設計成多個頁面 的，在頁面跳轉過程當中咱們須要知道用戶的狀態，尤爲是用戶登陸的狀態，這樣咱們在頁面跳轉後咱們才知道是否可讓用戶有權限來操做一些功能或是查看一些數 據。
咱們每一個頁面都須要對用戶的身份進行認證。固然，咱們不可能讓用戶在每一個頁面上輸入用戶名和口令。爲了實現這一功能，Web應用系統會把用戶登陸 的信息存放在客戶端的Cookie裏，每一個頁面都從這個Cookie裏得到用戶是否登陸的信息，從而達到記錄狀態，驗證用戶的目的。可是，Cookie的 使用並非簡單的事，下面是使用Cookie的一些原則。
1. 千萬不要在Cookie中存放用戶的密碼
千萬不要在Cookie中存放用戶的密碼，加密的密碼都不行。由於這個密碼能夠被人獲取並嘗試離線窮舉。因此，必定不能把用戶的密碼保存在Cookie中。
2. 正確的設計「記住密碼」
這個功能簡直就是一個安全隱患，一般的設計是用戶戶勾選了這個功能，系統會生成一個Cookie。Cookie包括用戶名和一個固定的散列值，這個固定的散列值一直使用。這樣，能夠在全部的設備和客戶上均可以登陸，並且能夠有多個用戶同時登陸。更安全一點的作法是：
1) 在Cookie中，保存三個東西——用戶名，登陸序列，登陸Token
 用戶名：明文存放。
 登陸序列：一個被MD5散列過的隨機數，僅當強制用戶輸入口令時更新（如：用戶修改了口令）。
 登陸Token：一個被MD5散列過的隨機數，僅一個登陸Session內有效，新的登陸Session會更新它。
2) 上述三個要素會存在服務器上，服務器須要驗證客戶端Cookie裏的這三個要素。
登陸Token是單實例登陸，意思就是一個用戶只能有一個登陸實例。登陸序列是用來作盜用行爲檢測的。
若是用戶的Cookie被盜後，盜用者使用這個Cookie訪問網站時，咱們的系統是覺得是合法用戶，而後更新「登陸Token」。而真正的用戶 回來訪問時，系統發現只有「用戶名」和「登陸序列」相同，可是「登陸Token」 不對，這樣的話，系統就知道，這個用戶可能出現了被盜用的狀況。因而，系統能夠清除並更改登陸序列 和 登陸Token，這樣就能夠令全部的Cookie失效，並要求用戶輸入口令。並給警告用戶系統安全。
3. 不要讓Cookie有權限訪問全部的操做
參考新浪微博的XSS攻擊，即便Cookie有權限訪問登陸以後的全部操做。下面的這些功能必定要用戶輸入口令：
 修改口令。
 修改電子郵件。
 用戶的隱私信息。
 涉及金錢的用戶消費功能。
(三) 找回口令功能
找回口令的功能必定要提供，目前經常使用的找回口令功能大體有如下幾種：
1) 安全問答。
事實證實，這個環節很煩人，並且用戶並不能很好的設置安全問答。什麼，個人生日啊，我母親的生日，等等。由於今天的互聯網和之前不同了，由於SNS，今天的互聯比之前更真實了，在facebook，開心，人人網，LinkedIn查到不少的真實的信息。
2) 重置用戶的密碼。
這有可能讓用戶的密碼遭到惡意攻擊
3) 安全一點的作法——經過郵件自行重置。
當用戶申請找回口令功能的時候，系統生成一個MD5惟一的隨機字串（可經過UID+IP+timestamp+隨機數），放在數據庫中，而後設置 上時限（好比1小時內），給用戶發一個郵件，這個鏈接中包含那個MD5的字串的連接，用戶經過點擊那個連接來本身從新設置新的口令。
4) 更安全一點的作法——多重認證。
好比：經過手機+郵件的方式讓用戶輸入驗證碼，還可使用數字證書、動態口令等方式。是否使用多重認證，主要取決於Web應用系統的重要性程度。
(四) 防護暴力破解
1) 使用驗證碼。
驗證碼是後臺隨機產生的一個短暫的驗證碼，這個驗證碼通常是一個計算機很難識別的圖片。這樣就能夠防止以程序的方式來嘗試用戶的口令。
事實證實，這是最簡單也最有效的方式。固然，老是讓用戶輸入那些肉眼都看不清的驗證碼的用戶體驗很差，因此，能夠折中一下。好比Google，當發現一個IP地址發出大量的搜索後，其會要求你輸入驗證碼。
2) 用戶口令失敗次數
設置口令失敗的上限，若是失敗過多，則把賬號鎖了，須要用戶以找回口令的方式來從新激活賬號。
可是，這個功能可能會被惡意人使用，形成用戶帳戶不能使用（這是一種變相的拒絕服務攻擊）。更好的方法是，結合IP地址作驗證，同時增長嘗試破解 的時間成本。如，兩次口令嘗試的間隔是5秒鐘。三次以上錯誤，賬號被臨時鎖上30秒，5次以上賬號被鎖1分鐘，10次以上錯誤賬號被鎖4小時等等。若是發 現來自同一IP地址的錯誤次數太多，正確的作法是禁止這個用戶在這個IP地址登陸，而不是單純的禁止用戶登陸。