驗證碼安全那些事

*原創作者：LionZ，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

最近在研究驗證碼安全，本文主要分析四種流行的驗證碼（圖形，簡訊，語音和滑動）進行分析，寫這篇文章的出發點並非是繞過或破解驗證碼，而是根據自身業務情況來選擇對應的驗證碼類型，在用戶體驗和安全性中找到屬於自己的平衡點。

有問題可與我聯繫Wechat：atiger77

0×01. 圖形驗證碼

0×02. 簡訊驗證碼

0×03. 語音驗證碼

0×04. 滑動驗證碼

0×05. 總結

備註：無論使用哪種驗證碼，只要開發不當都可能存在安全漏洞，為了減少文章重複內容，只在簡訊驗證碼中講解漏洞以及對應加固方案，在語音驗證碼中講解風控預防措施。

圖形驗證碼是出現最早也是使用最為廣泛的驗證碼沒有之一，從最早的簡單驗證碼到現在各種五花八門的驗證碼，為了防止被識別有加噪點的，有加干擾線的，有加各種背景的，有加邏輯題的…

之所以會有越來越噁心的驗證碼主要是防止驗證碼被機器識別，所設計的驗證碼難度也在不斷上升，相比較來看下面兩張圖就知道為什麼會這麼設計了。

一般識別流程:

一般驗證碼加固方法：

隨著驗證碼難度的提高識別的成本也隨即提高，為了進行識別測試，我分別收集了四家不同類型互聯網公司的驗證碼，情況如下：

某招聘網站驗證碼 – 字母周圍有噪點，字體扭曲

某電商網站驗證碼 – 不同樣式，字母陰影，字母粘連，背景色干擾

某社交網站驗證碼 – 主體干擾線，背景色干擾，背景字母干擾，字體扭曲，字母粘連

某生活類網站驗證碼 – 背景干擾線，背景色干擾，背景字母干擾，字體扭曲，字母粘連，字體鏤空

首先針對某招聘網站的驗證碼進行識別，這裡基於tesseract寫的一個OCR程序,測試樣本10張，最後準確率在50%，反溯以下發現對識別相近字時會比較吃力比如」z」和」2″，」0″和」O」等等，因為驗證碼做了反識別部分驗證碼人眼也比較難識別，如果繼續優化識別率達到70%左右應該問題不大。

接著對某電商網站的驗證碼進行識別，最後準備率在40%，由於該網站驗證碼難度各不相同對於這種類型的驗證碼比較難做統一處理，即使使用機器學習的方法一個模型也很難去識別所有的驗證碼。

後面兩個網站的驗證碼使用圖像識別去做難度就很高了，為了不被識別分別做了大量的反識別工作，那麼對於這類驗證碼一般使用的是人工打碼平台，之前有文章已經介紹過了這裡就不重複描述了。

這是某打碼平台的價格，網上可以找到很多類似的網站。

那麼對於企業來說，怎麼防止驗證碼被人工打碼呢，從安全形度來說是比較難做到防止的，為了不失去用戶體驗每張驗證碼的失效時間並不會很短，對於一個熟練的人工打碼人員來說完全不在話下，那麼我們從驗證碼本身出發去提高攻擊的一個成本，舉一個例子，可以使用DataURI scheme的方法把驗證碼圖片直接寫到HTML文件中去增加識別的時間和成本，當然還會有很多方法可以去增加攻擊成本。

如果想從根本去除打碼平台的困擾，這裡可以參考支付寶和微信這兩個產品的驗證碼機制，在某些地方所彈出的圖形驗證碼是和使用者有關，比如選擇聯繫人頭像，選擇購買過的物品，對於人工打碼的人來說是完全不知道答案的，但是用了這種類型的驗證碼也會出現問題，比如「好友」足夠了解你的情況下（個人信息泄露太多）可能會成功的進入。

現在有很多文章會用到神經網路CNN的方法用來識別驗證碼，相比傳統的識別用機器學習有了樣本的學習，識別率會更加的準確，對一些人眼可能判斷錯誤的字母機器或許能判斷準確，不過學習成本也是很高的。

簡訊驗證碼常見於註冊，忘記密碼，確認下單等階段，特別是一些涉及到用戶個人敏感行為時候，為了確認操作是用戶本人執行的通常會使用簡訊驗證碼進行二次認證。同時，簡訊驗證碼也是最為常見的驗證碼類型之一，這裡總結一些驗證碼邏輯漏洞。

a. 介面沒設頻次上限導致簡訊轟炸

起因：簡訊轟炸問題往往出現在一些小站或者子站，這幾年很少看到通過GET請求發送簡訊驗證碼了，基本都是使用POST請求，使用抓包軟體可以重放請求對於後端沒有做限制的網站就可以達到簡訊轟炸的效果。

危害：對用戶來說個人生活受到騷擾，對企業來說造成一定的負面影響，很多小公司因為簡訊介面被大量調用出現運營問題，對於公司沒有安全工程師的情況下，一般都是業務方發現了數據異常向上彙報，最後和開發一起反溯才會找到這個問題，那麼在這段時間中對企業所損失的錢也是無法挽回的。

預防：這裡主要是針對兩種攻擊場景來進行防禦，第一種是對單用戶的簡訊轟炸，即重放發送請求且phonenum為一個值。第二種是對多用戶發送簡訊騷擾的場景，即將phonenum參數設置為字典，重放簡訊介面。

設置發送間隔，即單一用戶發送請求后，與下次發送請求時間需要間隔60秒。

設置單用戶發送上限，即設置每個用戶單位時間內發送簡訊數的上限，如果超過閾值就不允許今天再次調用簡訊介面（閾值根據業務情況設置）。

設置單IP發送上限，這種情況是預防第二種攻擊場景的，由於IP的特殊性可能存在所處IP是大出口，一旦誤殺後果會很驗證，所以這個限制根據自身情況酌情考慮，對於有風控的團隊來說，當發現發送IP存在異常可以對該IP增加二次認證來防止機器操作，也可以降低誤殺情況。

備註：b和c兩個漏洞場景一般截圖說明下開發就知道問題所在了，這裡修復建議的內容寫的就比較少。

b. 驗證碼內容包含在返回包中

起因：因為開發不嚴謹導致通過抓包可以看到驗證碼在回顯中顯示。

危害：由於驗證碼直接返回，通過該漏洞可以註冊任意用戶，重置已註冊用戶密碼，修改綁定信息等高危操作，對用戶造成一定影響。

修復建議：不要將簡訊驗證碼在回顯中顯示，驗證碼只存於服務端中並不能通過任何api直接獲取。

c. 修改返回包內容繞過驗證

起因：前端校驗導致下列問題。

危害：可跳過正常校驗邏輯。

修復建議：服務端嚴格做檢驗，和開發談談心。

假設網站驗證碼介面沒有以上說的任何漏洞，那麼簡訊認證是否安全呢？

在用戶手機沒有被種木馬，用戶手機沒被強制降頻到GSM等情況下，當攻擊者無法獲取簡訊驗證碼則某些關鍵操作是無法繼續的，在一定程度上起到了攔截的作用。特別針對盜號的場景，由於設備或常用地發生了變化，在用戶登錄時候彈出驗證碼進行校驗防止被盜號的情況。簡訊驗證碼只對部分場景可以起到防護作用，單一的認證對於企業來說無法阻止以下的場景。

這張圖在我上一篇文章中出現過，這是在某打碼平台註冊了一個帳號的截圖，從圖上就可以看出雖然用了簡訊驗證碼，但是可以通過打碼平台來自動獲取並完成註冊流程。

針對打碼平台的垃圾註冊場景也可以通過一些手段去增加批量自動化的註冊成本，防禦手法有相同之處，在語音驗證碼中會簡單講解。

相比簡訊驗證碼，語音驗證碼存在以下的優勢：

a.語音驗證對防刷單效果更顯著；

b.語音驗證碼到達率更高；

c.用戶體驗更加友好；

為什麼說語音驗證碼對防刷單更有效，這裡貼一張某打碼平台的收費情況，可以看到語音驗證的價格是簡訊的十倍。很多公司是不會對17開頭的虛擬號段進行發送的，為此卡商提供的卡號基本是實名認證的且沒有停機的正常號段，所以收語音驗證的成本就會比簡訊高很多。

這家打碼平台對語音識別有兩種方式，一個是系統識別，另一個是自己聽取，對於系統識別平台解釋是由聽碼團隊負責聽取驗證碼後傳輸文字回來，自己聽取則是自己下載語音驗證碼錄音自己聽候識別。

跟公司研究移動端安全的小夥伴討論了下，根據目前的技術要做到全自動也並非不可能，這裡簡單畫了一個流程，從觸發語音認證開始到最後的填入完成驗證一條龍。

首先要獲取語音認證，等語音驗證碼說完以後自動保存錄音，進行語音分析，國內有幾家廠商有語音識別的服務並都提供SDK，所涉及的服務可以用來進行識別，將語音轉換成文字並提取驗證碼部分，完成最後驗證。

對於企業來說我們如何防止這種垃圾註冊的場景呢，說幾種通用的思路供參考，這裡主要可以分事前和事後基於規則和行為做判斷。

對於事前，可以藉助反欺詐介面檢測請求的號碼是否存在風險，WEB端判斷用戶UserAgent是否存在異常，APP端判斷用戶DeviceID是否存在異常，由於事前可以拿到的信息並不多，可以圍繞可以拿到的參數做規則，對觸發規則的用戶進行阻斷操作，可以在發送簡訊或者語音前讓其先填寫一次圖形驗證碼，多一步校驗。當然，也有公司會將部分手機號進行拉黑操作，在源頭上禁止某些手機號進行註冊。

對於事後，服務端校驗以後就可以拿到狀態等信息，圍繞這些信息又可以制定一些規則，這裡可以舉一個通用的規則，比如單位時間內單IP登錄失敗超過閾值的對這個IP進行某某處理，這也是最基本的頻次規則。對於不同的業務有著自己不同的策略，比如金融公司的APP會索取用戶通訊錄的許可權，根據用戶的好友做用戶畫像，某些公司也會做二度關係畫像來判斷用戶是否存在風險。

這裡不會說太多的規則和策略，由於公司的業務都不盡相同，當日誌接入以後針對目前場景存在的問題去設計不同的規則即可。

現在有不少的互聯網公司開始使用滑動驗證碼進行校驗，看似一個簡單的滑動操作，背後都有風控引擎和相應的規則作為保障，首先講一下滑動驗證碼的整個流程。

我們說一下正常的邏輯，首先用戶滑動驗證碼到指定位置，完成後會給服務端回傳各種加密信息，為了做風控規則來判斷是否異常，個人猜測其規則會包含用戶IP，操作行為路徑，UA,COOKIE，設備指紋等等，如果沒有命中規則，就會放行校驗通過，如果命中規則就會彈出二次校驗，只有通過校驗后才可以放行。

那麼如何破解滑動驗證碼呢，第一種是模擬正常用戶操作，並讓風控不要命中風控規則。第二種是嘗試破解第二階段的驗證，對於圖片可以使用OCR技術進行識別（針對類ReCAPTCHA驗證碼）。第二種的難度比較高，網上的文章也是針對第一種來進行破解，這裡簡單講一下破解方法。

我對某商業滑動驗證碼進行了測試，整體流程梳理如下：

全部過程可以用自動化來實現，整體成功率要分為兩個部分來看，第一是驗證碼自身風控能發現多少問題，我所測試的介面破解成功率在76%左右。第二是企業自身的風控規則能發現和阻斷多少異常情況。兩者結合最後的成功率就會有所下降，雖然有介面破解但是價格昂貴，已經提高了攻擊成本，如果賬戶不涉及到金錢也不會考慮這麼高的攻擊成本，其實說到底還是成本和收益的一個衡量。

這裡聊一下商業化滑動驗證碼廠商的優勢和弊端。首先說優勢，滑動驗證碼肯定會成為一種流行趨勢，對於企業來說自研的成本比較大，無非也就是幾個工程師參考已有的進行模仿，先不說效果開發流程上就會耽誤人力，這點錢寧願使用商業化的，現在的產品都已經相對成熟也有專門的團隊進行升級維護，安全和體驗性上來說都還不錯。弊端到也談不上，這裡主要說幾點使用前要考慮的地方，一個是響應延遲，當大量併發過來的時候是不是撐得住，最高響應時間是否有上限，如果超過是否會降級，如何降級等等，萬一碰到不可預計的問題，比如碰到光纜被挖斷，服務是否能即使切換，災備是否完善等等，在購買前這些問題最好都要進行測試並有應急方案。

前面也總結了很多驗證碼，我認為一個好的驗證碼首先不能有邏輯上的漏洞能繞過，否則再複雜的驗證碼都是形同虛設。其次，不能為了增加破解難度而拋棄用戶體驗，不要把驗證碼做的極其複雜人眼都識別不了，這種也會失去驗證碼的意義（用戶都沒了還給誰驗證…）

目前來說大部分的企業還是偏向使用圖形驗證碼，在測試過程中只有極少數的公司會動態升級自己的圖片驗證碼，隨著輸錯次數的上升驗證碼難度也隨機上升。統一驗證碼的設計初衷是好的，即使攻擊者使用了OCR技術進行破解，一旦失敗數觸發到閾值即自動上升圖形驗證碼難度，增加破解成本。

為了防止驗證碼被爬蟲獲取后專門進行分析，針對性的破解攻擊，需要準備多套圖形驗證碼定期進行替換。

統一驗證碼體系如果只用單純的規則去匹配所彈出的驗證碼，那麼這種情況會出現不少的誤殺，會讓某些正常用戶操作頻次超過設定閾值，用戶在嘗試輸入密碼的過程中驗證碼越來越難，最後導致用戶投訴。所以我認為一個完善的統一驗證碼體系應該由風控來判斷是否觸發規則，對觸發規則的請求進行相應的驗證升級，而不是設定一個死的閾值，對關鍵操作可以用多種驗證碼組合的形式來進行校驗，常見的組合有，滑動+圖形，圖形+語音等。

就我個人而言，比較喜歡點觸式和滑動式的驗證碼，通過採集用戶當前各種的參數行為（行為軌距，操作時間，當前環境等等）來判斷是否為機器行為。在用戶體驗上，手機端不是很建議使用選字類型的驗證碼，對於非大屏的手機不是很友好。在安全性上，這類驗證碼要比其他驗證碼破解成本高。我相信驗證碼的趨勢也會逐漸向這種類型的靠攏。

下面的圖片引用了google的ReCAPTCHA，分別截取圖片和語音驗證，ReCAPTCHA在安全性和用戶體驗做的都很好，即使這樣還是被安全研究者破解過，所以不要完全依賴一種驗證碼，對敏感操作可以使用多種驗證碼。下面是官網的DEMO：

圖片類：

聲音類：

無論哪種驗證碼都有自己的適用場景，也沒有一種絕對安全的驗證碼，根據自身業務情況來選擇對應的驗證碼類型，在用戶體驗和安全性中找到屬於自己的平衡點。最後，有做業務安全的同學可以一起學習交流。