使用者登入功能是web應用系統具備的最基本的功能，關係到使用者資料和應用系統資料的安全，設計乙個安全的使用者登入功能，涉及到以下幾個方面的內容。
(一) 老生常談——口令
1. 口令長度與複雜度限制
限制使用者輸入一些非常容易被破解的口令，比如qwert、asdfg、123456、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有許可權訪問所有的操作
修改口令。
修改電子郵件。
使用者的隱私資訊。
涉及金錢的使用者消費功能。
(三) 找回口令功能
找回口令的功能一定要提供，目前常用的找回口令功能大致有以下幾種：
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位址登入，而不是單純的禁止使用者登入。
注：**於
使用者登入如何設計測試用例
一 a.輸入已註冊的使用者名稱和正確的密碼，驗證是否登入成功 b.輸入已註冊的使用者名稱和不正確的密碼，驗證是否登入失敗，提示資訊是否正確 c.輸入未註冊的使用者名稱和任意密碼，驗證是否登入失敗，提示資訊是否正確 d.使用者名稱和密碼兩者都為空，驗證是否登入失敗，提示資訊是否正確 e.使用者名稱和密...
如何設計乙個安全的登入流程
登入是系統中最重要的乙個功能之一，登入成功就能擁有系統的使用權利，所以設計乙個安全的登入流程是十分必要的，那在一般登入中需要考慮哪些重要因素呢？我們一一列表一下。使用https協議進行傳輸，雖然麻煩，但是很強的保護措施。強制使用者使用有一定強度且複雜的密碼，必須要有大小寫加數字，長度在8位以上，杜絕...
測試「使用者登入」功能
如何測試 使用者登入 功能？我認為可以從功能性和非功能性兩個維度去思考。關於功能測試，首先可能會根據 使用者登入 功能的需求描述，結合等價類劃分和邊界值分析方法來設計測試用例。包括 輸入已註冊的使用者名稱和正確的密碼，驗證是否登入成功 輸入已註冊的使用者名稱和不正確的密碼，驗證是否登入失敗，並且提示...