當咱們談論驗證碼時，咱們到底在談論什麼？

前言：

現現在登陸用手機驗證碼登陸是愈來愈常見了。雖然會增長成本，不過對用戶體驗的提高仍是頗有幫助的。那麼，當產品經理對開發說，來按照這個原型給我搞個短信驗證碼登陸的時候。咱們做爲研發，應該想些什麼？

短信登陸要作的事情

這裏的圖只展現了一次成功的流程。還有不少細節值得展開講下。除了短信驗證的流程之外，登陸的安全性也必需要考慮到。尤爲是比較重要的後臺項目。
下面我就想圖中17個步驟拆開分析

請求獲取驗證碼（1~4）

1~4步主要的點有兩個。

1. 前端對手機號的格式驗證，按鈕屢次點擊的驗證
2. 後端對請求驗證碼的頻率的限制

驗證規則能夠寬鬆一點。雖然前端的驗證並不可靠，可是不表明前端的驗證沒有用。同時，當點擊了獲取驗證碼後須要將驗證碼的按鈕禁用，防止屢次點擊
後端的部分則須要判斷當前ip，當前手機號是不是重複請求驗證碼。這裏就須要引入重複請求驗證碼的規則。通常的規則是60秒內能夠再次請求。這個時間能夠經過記錄一條鍵名爲請求手機號的一條緩存，過時時間爲60秒。若是能夠拿到值，則說明尚未到60秒再次請求。

驗證合法性（5~8）

5~8步主要是驗證手機號背後的用戶的合法性
首先手機號的格式是必需要判斷的，雖然前端有判斷。可是後端的驗證纔是可靠的驗證。後面就是經過手機號查庫。查詢的邏輯主要爲

1. 註冊用戶中是否有這個手機號
2. 該用戶狀態是否爲禁用
3. 該用戶權限是否能夠登陸當前業務

若是條件知足就能夠進行下一步了

製做/存儲驗證碼（9~10）

製做驗證碼，就必須考慮兩個問題，1是驗證碼的長度 2是驗證碼的複雜度
對用戶最友好的固然是純數字，驗證碼越短越好。可是這樣對安全性就大打折扣。有沒有又對用戶友好，又安全的方案呢？
答案是有的。
首先咱們假定使用4位數字的方案。若是不設置嘗試次數的限制的話，黑客使用多線程工具，在短期內進行暴力枚舉最多1萬次就能窮舉出全部的可能，並且運氣也不必定會這麼差。有可能在3000次的時候就試出來了。
那麼咱們的解決方案就是。同一個手機號，驗證三次。就將驗證碼失效。在3次失敗後，第四次請求，就返回錯誤文案 「驗證碼連續錯誤三次，請從新獲取短信驗證碼」
還有一個須要思考的維度。那就是短信驗證碼的有效期。通常來講，短信驗證碼會有5分鐘的有效期。這裏就會有一個交叉的問題。好比一個用戶獲取到了一個驗證碼而不去驗證，過了60秒又去獲取一次。他就會有兩個有效的驗證碼。這樣明顯是不合理的，那麼我就須要在獲取第二次驗證碼的時候廢棄調第一個驗證碼。使用緩存存儲驗證碼的時候，直接set就能夠將上一個驗證碼給覆蓋掉，還能夠從新設置5分鐘的有效期。

最後還有一個容易被忽略的問題。那就是短信防刷，咱們以前的設置，都只是針對於一個手機號的防刷。還有一種刷短信是不停的更換手機號來刷的那種。解決方案能夠經過，ip，ua，referer,header等參數來判斷是不是同一個客戶端發起的請求。若是是同一個客戶端在一個小時內請求超過了5次。就必須輸入一個圖形驗證碼。圖形驗證碼的實現就不用多說了。太多能夠直接用的包。這樣的話能夠最大限度的防止別人對咱們的系統進行攻擊，同時也保障了體驗不打折扣

發送驗證碼給用戶（11~12）

這步就比較簡單了。只須要按照SMS的接口文檔，傳入手機號，短信模版，驗證碼就能夠發送了。能夠考慮增長一個日誌記入數據庫，用做數據分析。

驗證登陸,登陸成功（15~17）

驗證登陸這步主要是要完成以前提到的。驗證3失敗3次廢棄驗證碼（不管是否匹配），驗證經過後也要廢棄驗該驗證碼。同時驗證碼經過以後仍是須要再次驗證用戶的合法性。防止比較極端的狀況，好比請求驗證碼的時候用戶是合法的，可是在5分鐘以內用戶被禁用了。這樣的話仍是不能讓他登陸。
登陸成功的話就看本身的架構設計了。能夠是token令牌也能夠是session會話。創建會話以後，就算完成了一次完整的短信驗證碼登陸了！~

總結

總結完成以後，就能夠按照要求進行開發了。雖然是一個簡單的短信驗證碼，可是我發現市面不少的項目，這一塊都沒有作好（別問我，我怎麼知道 哈哈哈）咱們做爲研發人員，必定要儘量的考慮周全，以避免出現線上事故。

微信公衆號：RichardTalked