再見了，打碼平台：對抗打碼平台的驗證碼思路

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

某日，一朋友深夜微信上問我，如果打碼平台盯上了你，你該咋整？

政治正確的回答方式是：加強風控策略，多維度判斷使用者意圖，減低對驗證碼的依賴。

顯然這不是我或者朋友真正想要的，現在不少企業面對打碼平台有時候束手無策，只能放棄對驗證碼的依賴，我覺著有點可惜。

我們先來回顧一下，驗證碼的學名是啥？

圖靈測試。

圖靈測試的目的是為了區分人與機器，而打碼平台的加入使得這個過程立即無效——打碼平台上活躍的對象還真是人。

但這樣就沒轍了么？

No。

這「人」與「人」之間是有差別的。我們仔細想想，我們加入驗證碼的目的其實除了圖靈測試之外還有一個重要的潛在期望——我需要知道你的確是你。

絕大部分需要部署驗證碼的地方其實都有具體和人或行為關聯的信息，例如登錄、下單、領券、支付等；少數部分信息可能和人沒有那麼強的關聯，比如搜索、匿名評論等。可無論如何，驗證碼是對一個具體的動作進行「人」機識別需要時才產生的。這裡指的「人」是某些信息本身的擁有者。

我們看看過去的驗證碼都有什麼類型：

1、字元型驗證碼

這個太簡單了，不再舉例。

順便吐槽一下，就算是個簡單的字元型驗證碼，很多人卻設計的像狗屎，這其中包括了一些安全公司或具有安全屬性的產品。基本的字元黏連、形變都沒有，光用誇張的混淆色、噪點，一個二值化就如同裸體相親一樣讓人一見長短，實在垃圾。

2、簡訊驗證碼

這種類型的驗證碼分為兩種（用戶主動發送和用戶被動接收），通常用在多因素認證中。

被動接受型的驗證碼對於驗證碼發起方（伺服器）來說成本很高（簡訊收費）。有些情況下，簡訊驗證碼本身就是需要被保護的對象（簡訊轟炸）。

主動發送型驗證碼對於用戶體驗極差（需要用戶進行大量操作，用戶需要為你的風控策略付費），除非這項業務已被壟斷（例如某購票系統），否則老闆幾乎不會同意你這麼做的。

況且這兩種驗證碼都有收碼平台可以無縫覆蓋，單純用作圖靈測試沒啥意義。

3、問答驗證碼

這是一個大類，包括百度貼吧的看拼音選漢字的驗證碼、12306的看文字選圖片驗證碼、Google norecaptcha的二次圖片驗證，或者網上爆料出來叫你展開傅里葉級數統統都是問答型驗證碼的一種。

這種驗證碼的前身是題庫，題庫本身存在中容易被窮舉的弊端。其他「高級」問答型驗證碼的安全性，則除了依賴計算機視覺功能受限外，還依賴於人類的認識活動無法被機器模擬的大前提。

對於打碼平台來說，問答型驗證碼還是輕而易舉的（你要是用高數題作驗證碼算我沒說）。

4、字元型行為驗證碼

常見的有Google norecaptcha第一次驗證或者常見的一些拖動型的驗證碼。這些驗證碼每個都聲稱自己用了什麼機器學習、大數據分析、人類行為建模等等一大堆聽起來就很牛逼的技術。

5、語音驗證碼

語音驗證碼大多屬於無障礙設施的一種，為的是視障人士也能正常通過驗證，後來演化成對抗貓池的方向之一（需要接聽來電）。之前還出現過Google recaptcha被Google自己的語音識別API干翻的趣事，這裡也不再一一展開。

上面這些驗證碼呢，應該基本覆蓋了日常能見到的絕大部分場景，也是打碼平台或者收碼平台存活下去的基礎。

大家有沒有發現，這些驗證碼有一個共同的特點：上下文無關。

這裡我們定義一個概念：上下文無關驗證碼。

上下文無關驗證碼是一個問題與答案或規律一一對應的集合，對於任意給定問題，一定能通過問題本身得出答案。

同學們，劃線部分是重點，打碼平台要考啊！！！

用通俗一點的話說，就是任意的驗證碼都是完全獨立和與具體場景的上下文無關的。比如說，我的這個驗證碼既可以在登錄場景中能用到，也能在下單場景上使用，無論是對A用戶還是對B用戶，同樣的驗證碼也能適用。甚至說，你把驗證碼隨便截個圖發給IM上的好友，他立馬知道什麼意思。某購票系統的驗證碼變態吧，但是你試試看把他截個圖別人能答不能答？

既然驗證碼的應用有場景性，也有具體的上下文，那我們以前都沒用到幾個「參數」，我們是不是可以考慮用它一下？

我們再定義一個概念：上下文相關驗證碼。

上下文相關驗證碼是一個上下文、一個問題與一個答案對應的三元組，對於任意給定問題，能且僅能在具體上下文下得到對應答案。

這裡的問題設計是有技巧的，它需要滿足一個條件：上下文包含的內容中存在用戶不願或不宜公開的信息，且該信息伺服器知曉。

用一句話來形容一下這一類的驗證碼：就算截圖發給基友，他也不能給出正確答案。

怎麼，這樣的形容很模糊，不夠形象？

那我舉個具體的例子，場景是登錄。

以前，當一個人的登錄行為遇到風控策略時，往往會在輸入賬號密碼的同時輸入驗證碼。

現在，我們把驗證碼輸入策略稍稍往後推一步——在用戶提交完賬號和密碼後要求輸入這樣一個驗證碼：

我們設想一下，如果機器或打碼平台需要識別出這個驗證碼要滿足什麼條件：

做題者需要是人，或具有相當精度的OCR工具（OCR識別幾乎不能有錯）；

做題者需要知道這個提交者的賬號和密碼明文；

那麼，這樣一樣來，先不說打碼平台如果能實現後費用必須各種增加，光這第二點就會把打碼者和攻擊者之間的利益約束消滅：既然我已經知道了賬號密碼，要你攻擊者何用？而對於做題者即是提交者來說，這樣的設計不會帶來什麼問題。

我們顯然可以推測——攻擊者自身無法通過OCR識別這個驗證碼的話，也不願意將這種類型的驗證碼往外眾包。否則，打碼平台或者打碼者可以開展大型的黑吃黑活動（如果界面上有水印，做題者還知道這個驗證碼的來源），攻擊者的風險與收益不再成比例，自然也沒有人願意搞事兒了。

除了登錄場景之外，我們在下單、領券、加好友等等的時候也可以應用類似的策略：

請選擇下圖中您手機號【沒有/有】包含的數字。

請選擇下圖中您地址中【包含/不包含】的【省份/縣市/具體地址】。

請選擇下圖中您獲取優惠券名稱中【包含/不包含】的漢字。

請選擇您要添加的好友名稱。

可惜的是，這個驗證碼部署成本很高。因為它不在像之前的驗證碼一樣，能夠做到「一次設計處處可用」。上下文相關驗證碼則必須對具體場景的上下文設計一個具體策略，這點和風控與業務的高耦合很像。部分大廠也部署了類似的策略，只不過他們更多的把它定義為「安全驗證」。

本文只是拋了塊磚，希望給大家在設計驗證碼的時候可以有一個新的思路。標題可能有些誇張，還請海涵。

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！