在很多Web網站中，有一項功能是忘記密碼，不同網站對忘記密碼的策略有自己的一套方案。但是目前卻缺少一個工業標准實現一個忘記密碼功能，導致的問題就是有可能在某些流程中出現漏洞，被hacker盜取賬號。
OWASP作為Web安全公認的組織，在這里提出了自己的標准。下面是它的幾個步驟。最后會用支付寶作為例子分析一遍。
博客園的排版不是很好，同樣的文章在我的github上查看，排版比較好：
http://blog.bensonlin.me/blogs/forgot-password-cheat-sheet
轉載需加上該地址
如果寫得不錯，別忘了關注我哦
Step 1) Gather Identity Data or Security Questions
第一步：收集用戶身份數據或者安全問題
第1步一般讓用戶填寫以前自己填寫過的數據（一般是在用戶注冊的時候填寫的），也就是查詢數據庫中是不是有這個賬號的信息，
這一步收集的信息里，至少要包含可以用來發送重置密碼消息的第三方信息，這些信息可以是郵箱地址或者手機號等等，第3步時要用到。
Step 2) Verify Security Questions
第二步：校驗安全問題
第1步的信息提交后，應用校驗每一個數據，如果有錯誤，或者用戶名(username, 應該是用戶的某個標識)沒有被識別，第二頁可以展示錯誤的信息。如果是正確的，第二頁應該展示至少兩個用戶之前提交的兩個安全問題，讓用戶在輸入框中輸入，輸入框應當是一個HTML表單的一部分。
注意，不能夠提供下拉列表讓用戶選擇自己想回答的問題，這里我不是很懂，可能想表達的意思是：如果有多個問題，不能讓用戶只選擇一個回答，這樣防御能力會變弱，影響安全性。
當表單提交的時候，應避免發送用戶名作為參數(不管是不是hidden域)，用戶名應該儲存在服務端的session中，在獲取的時候應該從session中獲取，而不是提交表單的形式獲取。（如果不做到這樣，hacker可以建立另一個賬號，通過輸入自己的標識和自己的問題和答案繞過這一步）
因為用戶填寫的那些安全問題一般比細心選擇的密碼更加的不安全（如典型的問題有 你最喜歡什么運動，你出生在哪個城市等等），因此，應該限制猜測的次數，這個閾值可以控制在3到5次之間，當還是錯誤時，要鎖定用戶的賬戶一定的時間（比如5分鍾），以避免hacker猜測問題，重置了用戶的密碼，
然后通過質疑令牌(challenge token)質疑用戶身份，進入下一步的多因素認證流程
因為有可能認為用戶的個人信息已經泄露，因此發送的令牌token不能包含一些個人信息如手機號碼或者email等
Step 3) Send a Token Over a Side-Channel
第三步：發送質疑令牌到第三方渠道
第2步之后，應當立即鎖定用戶的賬戶，然后采用8位或以上的隨機數作為token發送到第1步填寫的個人信息中（比如郵箱或手機上）；
在這里引入了另一個外部渠道，增加了防御的深度，令黑客更加難通過驗證。這樣如果有黑客成功通過了第一二步，他也可能會在這一步被攔住。
同時，這個隨機數應當只有一定的生命周期，也就是一定的存活時間，如不超過20分鍾左右。如果用戶沒有及時的查看郵箱，那么這個郵箱將不能再被使用。如果沒被用戶用來重置密碼，token也不能再被使用(如收到驗證碼后不理它)；當然，在成功重置完密碼后token不能再使用，應當銷毀。
Step 4) Allow user to change password in the existing session
第四步：要求(require)在現有會話(即第二步填寫的安全問題時所在會話)中輸入第三步發送的token，如果不及時輸入，將不能成功；
可以通過展現一個HTML表單，里面包含3個輸入域，一個token輸入框，一個新密碼輸入框和一個確認密碼輸入框；
校驗時，應確保令牌是正確的，而密碼是足夠復雜的。同樣的，應當避免用戶名作為表單參數被提交。
最后，檢查用戶是不是繞過了前面的步驟進入這一步的，也就是驗證是否是從合法的頁面來的，否則有可能引入強制瀏覽攻擊（forced browsing attack）
實例
支付寶的忘記密碼功能是很規范的，可以參考它的忘記密碼流程
第1步：標識憑據
使用手機號或用戶名作為標識 里面需要添加了驗證碼，是為了有人防止惡意嘗試電子郵箱或手機號，進入第2步。
第2步：填寫安全問題
可以看到有 驗證短信+驗證身份證件 和 驗證短息+回答安全保護問題，當然通過人工服務就沒什么說了,只要是自己賬號，基本上人工是可以解決的，現在看看第二種方式，即驗證短信+回答安全保護問題
可以看到需要先發送驗證嗎，驗證身份信息，其實都是為了防止，這里就是第三步的內容 短信中提示30分鍾內輸入，而安全保護問題也是問我的出生地，可能是我之前填寫的，我自己也忘了，然后修改了原來的問題，修改成3個問題，用來驗證它是不是隨機選擇問題，后來發現居然你問多少個問題就要回答多少個問題，挺安全的 TAT。
其中的驗證碼是第3步的質疑令牌
題外話：從重置密碼中可以看到可以使用身份證重置，我點進去看了一下，就我而言，不是很認同這種重置方式，雖然有通過收手機驗證碼方式，但是身份證號泄露還是不難的，也就是只有手機這個方面能夠有效防御，換句話說，就是給入侵者減少了一道防御，不過就方便而言確實方便很多，當然，安全和方便總是矛盾的。 
第3步：發送質疑令牌
因為第1步填了手機號，所以第3步支付寶將驗證碼發到了手機上
手機信息如下： 【支付寶】您正在修改登錄密碼，校驗碼257***，請於30分鍾內輸入，工作人員不會向您索取，請勿泄露。
驗證碼長度為6位，有效期為30分鍾，這個是網站自己定義的。
第4步：修改密碼
需要在當前會話中完成，因為有事中途走開了，然后我刷新步驟3的頁面，發現這樣子了
接着我重復前面的步驟，回到了填寫安全保護問題的步驟，填寫了正確的安全保護問題后，進入了重置密碼階段
輸入新的密碼確定就可以了，當然修改密碼后token肯定就銷毀了 
題外話：當我輸入的密碼和之前的相同時，提示我”新登錄密碼必須和當前登錄密碼不同”，在一次保證了安全，有意思，大家可以試一下
小結
結合OWASP推出的忘記密碼方案和支付寶的實例，我們可以發現其實很多網站對忘記密碼的處理都不是很恰當。也警示我們寫程序應該遵循一定的步驟走，不應該擅自的修改步驟，否則很可能會出現問題
有什么問題歡迎指出