如何設計簡訊驗證碼防刷機制

最近遇到一個關於防止簡訊驗證碼被刷的產品設計問題，後來在面試一個前來應聘JAVA開發的程序員的時候，他也提到了他以前公司的系統也遭遇過這個被刷簡訊的問題。因此，就「如何設計簡訊驗證碼防刷機制」作一個總結和分享。

現在，大部分的產品都會涉使用到簡訊驗證碼的介面，特別是移動產品，簡訊驗證碼幾乎成為了所有移動產品的標配。因此，防止簡訊被刷也就成了每一個產品經理和開發者關注的問題。

沒有遇到過簡訊被刷問題的產品經理，或許對於這個問題並不是很重視。在此，先簡單介紹一下刷簡訊的黑工具——簡訊轟炸機。簡訊轟炸機就是一個利用寫好的程序來大批量刷簡訊的軟體，它能夠通過自動批量提交手機號、模擬IP等方式去刷簡訊。

因此，我們在設計需要用到簡訊驗證碼的產品的時候，一定要制定限制規則，避免簡訊被刷光。

防刷的常見做法，估計大家都不會陌生，PC時代，大部分平台都是通過圖形驗證碼的形式來減少平台被機器所刷的風險，最典型的例子莫過於12306的「奇葩驗證碼」了。然而，在移動互聯網時代，用戶的體驗非常重要，有時候使用圖形驗證碼的同時會對用戶的體驗有一定的影響。那麼，除了圖形驗證碼的方式之外，還有哪些方法能夠解決簡訊被刷的問題呢？以下提供幾種方式可供參考：

1、時間限制：60秒後才能再次發送

從發送驗證碼開始，前端（客戶端）會進行一個60秒的倒數，在這一分鐘之內，用戶是無法提交多次發送信息的請求的。這種方法雖然使用得比較普遍，但是卻不是非常有用，技術稍微好點的人完全可以繞過這個限制，直接發送簡訊驗證碼。

2、手機號限制：同一個手機號，24小時之內不能夠超過5條

對使用同一個手機號碼進行註冊或者其他發送簡訊驗證碼的操作的時候，系統可以對這個手機號碼進行限制，例如，24小時只能發送5條簡訊驗證碼，超出限制則進行報錯（如：系統繁忙，請稍後再試）。然而，這也只能夠避免人工手動刷簡訊而已，對於批量使用不同手機號碼來刷簡訊的機器，這種方法也是無可奈何的。

3、簡訊驗證碼限制：30分鐘之內發送同一個驗證碼

網上還有一種方法說：30分鐘之內，所有的請求，所發送的簡訊驗證碼都是同一個驗證碼。第一次請求簡訊介面，然後緩存簡訊驗證碼結果，30分鐘之內再次請求，則直接返回緩存的內容。對於這種方式，不是很清楚簡訊介面商會不會對發送緩存信息收取費用，如果有興趣可以了解了解。

4、前後端校驗：提交Token參數校驗

這種方式比較少人說到，個人覺得可以這種方法值得一試。前端（客戶端）在請求發送簡訊的時候，同時向服務端提交一個Token參數，服務端對這個Token參數進行校驗，校驗通過之後，再向請求發送簡訊的介面向用戶手機發送簡訊。

5、唯一性限制：微信產品，限制同一個微信ID用戶的請求數量

如果是微信的產品的話，可以通過微信ID來進行識別，然後對同一個微信ID的用戶限制，24小時之內最多只能夠發送一定量的簡訊。

6、產品流程限制：分步驟進行

例如註冊的簡訊驗證碼使用場景，我們將註冊的步驟分成2步，用戶在輸入手機號碼並設置了密碼之後，下一步才進入驗證碼的驗證步驟。

7、圖形驗證碼限制：圖形驗證通過後再請求介面

用戶輸入圖形驗證碼並通過之後，再請求簡訊介面獲取驗證碼。為了有更好的用戶體驗，也可以設計成：一開始不需要輸入圖形驗證碼，在操作達到一定量之後，才需要輸入圖形驗證碼。具體情況請根據具體場景來進行設計。

8、IP及Cookie限制：限制相同的IP/Cookie信息最大數量

使用Cookie或者IP，能夠簡單識別同一個用戶，然後對相同的用戶進行限制（如：24小時內最多只能夠發送20條簡訊）。然而，Cookie能夠清理、IP能夠模擬，而且IP還會出現區域網相同IP的情況，因此，在使用此方法的時候，應該根據具體情況來思考。

9、簡訊預警機制，做好出問題之後的防護

以上的方法並不一定能夠完全杜絕簡訊被刷，因此，我們也應該做好簡訊的預警機制，即當簡訊的使用量達到一定量之後，向管理員發送預警信息，管理員可以立刻對簡訊的介面情況進行監控和防護。

以上所說到的方式，或許不是很完美，但是可以通過多個方式結合著來作使用，通過多個規則來降低簡訊被刷的風險。

如果您有更加好的方式，歡迎一起分享。

原創聲明

本文為風笛原創，轉載請聯繫公眾號zuopmcom，並保留文章中的二維碼。

推薦閱讀：