驗證碼對抗之路及現有驗證機制介紹

yahoo郵箱在九幾年的時候,業務深受各類郵箱機器人的困擾,存在着大量的垃圾郵件,因而他們找到了當時仍在讀大學的路易斯·馮·安(Luis von Ahn),並設計了經典的圖形驗證碼,即經過簡單的扭曲圖形文字進行機器的識別。html

經過這個簡單的圖形,他們很快的控制住了垃圾郵件的數量,並將大量的機器人據之門外。前端

可是即便驗證碼解決了垃圾郵件的問題,咱們仍要提出一個問句:web

 

驗證碼是必要的嗎?

阿里有句簡單的話:不忘初心,方得始終。算法

驗證碼不是一個功能性的需求,他並不能帶來業務的提高,也不能帶來任何價值。chrome

驗證碼只是爲了解決機器問題才誕生的。在設計和驗證碼演化的過程當中,必須同時考慮安全性和體驗。數據庫

 

讓咱們老考慮驗證碼的最簡化模型,關鍵點在於:生成的問題可以由人來解答,而且機器難於解答。安全

因而傳統的圖形驗證碼的重點就放在瞭如何生成讓機器難於解答的圖片上來。cookie

 

從上圖看來,相應的各類方法已經有了至關成熟的一些對抗辦法,更不用說如今已經普遍氾濫的打碼平臺了。機器學習

結合咱們安全性和體驗兩方面來說,傳統驗證碼在兩方面來講都已經不能知足要求了。函數

 

樹林裏分開了兩條路

如今隨着攻防的升級和對抗的不斷增強,驗證碼的面前針對安全性和體驗這兩個關鍵點分出了兩條路:

  • 從體驗上來:基於人類用戶的行爲
  • 從安全性上來:基於人類認知問題的答案

 

基於人類認知問題的答案,咱們已經遇見過不少種了,這裏簡單貼兩個:

 

固然也存在這類:

 

簡要分析,優勢明顯:機器沒有這個認知能力(廢話,好多我都作不出來)

 

存在的問題有:

1.題庫維護的難題。若是題庫被遍歷完成,那麼其安全性沒法保證。

12306爲何後面把問題變成了圖片呢? 由於有攻擊者將每次的答案與出現的可選問題進行了屢次重複遍歷,當這個遍歷到達必定次數後,會發現某個答案與某張圖經常會關聯出現(由於問題一定會有正確答案),經過這個出現機率便可獲得答案。因而,12306才把文字變成了如今扭曲的圖片。 而且還有研究人發現,12306的圖片可能大量來自某百科,經過逆向使用該公司的圖像識別服務,能夠獲得該圖片的部分標籤。

 

2.體驗差

過年的時候,正常人平均都要答三、4次才能答對答案。並且部分圖片由於分辨率不高、再加上縮小圖片之後,會更加的看不清了。

基於人類用戶的行爲,具體點就是用戶在進行相應操做時,會產生的操做記錄和環境信息(詳見設備指紋一文)等。

基於人類用戶行爲這條路是基於如下基礎的:

  • 機器人的環境有別於正經常使用戶
  • 機器人的動做或頻率等有別於正經常使用戶
  • 機器人的在相應關鍵業務點的行爲邏輯有別於正經常使用戶

 

可是這個基礎在技術對抗上有個更關鍵的點,在於如何構建一個安全的信道,將這些數據回傳回來。若是這個信道的採集機制、加密機制和傳輸機制被攻擊者所探知,那麼以上採集的信息將沒有祕密可言。(換句話說,攻擊者會假裝成正經常使用戶的行爲發送數據)

阿里所採用的前端採集和加密機制,利用自動化混淆、加密函數隨機選擇、線上自動迭代等能力將web前端打造爲了一個可信的端,並將數據回傳。(詳見驗證碼的前世此生系列

 

該類方法的優勢:

收回了對用戶的強打擾將基於知識和問題的對抗轉變爲前端加解密採集等機制的對抗若是攻擊者沒法攻破這一層堡壘,即便打碼平臺存在也沒法攻擊成功

缺點:

加解密機制須要作到足夠強,而且須要擁有攻擊感知能力、線上的自我變動能力和自動化測試等能力

咱們選擇了同時走兩條

基於上述思考,阿里滑動驗證綜合考慮兩種類型的方法,結合並推出了滑動驗證的體系:

經過基於用戶行爲的第一道防護將對正經常使用戶的打擾下降,使得正經常使用戶能夠以極小的代駕經過滑動驗證,而同時對不肯定的用戶實施知識型問題的驗證,在攔截機器人的同時,保障業務的正常平穩運行。

再看看google先階段的norecaptcha:

能夠看到,google的模式與阿里的模式有些相似,所不一樣的是google所使用的驗證碼模式是點擊,而阿里是滑動。

簡單分析下google,對於第一步的點擊驗證,google更多的是經過其基於虛擬機的強混淆器對整個數據採集過程進行了加密,並綜合了環境信息(如設備指紋、cookie、點擊頻率等信息)來進行判斷,而第二步的知識驗證也包括如下幾種(部分在以前的圖中沒有出現):

  • 1.扭曲的圖形
  • 2.圖形的分類
  • 3.高級圖形分類(會不斷的出圖,點完一張又一張)

 

那這樣是否就是驗證碼問題的銀彈呢?

以前已經提到過,不管是google的norecaptcha仍是咱們的滑動驗證,其核心都在於其自己的風控引擎和相應的規則,對於攻擊者來講也有兩條路:

  1. 正面強行突破,破解前端的密文、而後模擬正經常使用戶行爲,達到直接經過的目的
  2. 退而求其次,經過觸發二次驗證過程,而後經過ocr或者打碼等其餘方法經過

 

rsa上針對googlenorecaptcha的破解

4月8日,BlackHat上公佈了一篇來自哥倫比亞大學的論文,大體上講了他們是如何突破google的norecaptcha驗證碼的。

簡單說明下他們的破解過程:

1.攻擊者經過大量的模擬器及代理IP來僞造Browsing History及Browser Environment來Fuzz測試Google的風險分析系統。測試過程當中發現包括Useragent、Canvas Fingerprint、屏幕分辨率、鼠標行爲動做衆多因素均爲風險判斷的因子,風險判斷決策返回結果隨機且有嚴格的次數限制;

好比,攻擊者發現,修改user agent、使用firefox而聲稱chrome等會致使norecaptcha出現回退,即出現普通的驗證碼。

 

2.在得出了這些參數與最終結果的關係後,也沒有正面突破,走到了第二個思路,通過fuzz嘗試後,發現google的容錯性較高,即即便圖中只有2個正確答案,你若是點擊了3個圖,包含兩個正確答案,也算正確。而且,根據基於次數的統計發現,norecaptcha中出現答案的比例較多的爲2個答案(74%),所以,攻擊者很聰明的選擇了每次選擇3個圖像的方法,由於這樣作可使得每次成功的機率提升(畢竟多選了一個可能正確的答案,即便選錯了也能夠對)。

3.同時,在大量的fuzz面前,攻擊者們發現有些圖片會時不時的出現。出現次數最多的一個圖片出現了12次。他們開始意識到這些圖片並非實時生成的,而是從一個已經生成好的池子中生成的。重複的利用,也就意味着大規模的可能性。

儘管google生成的圖每張的hash值不一樣,可是利用感知hash算法(Perceptual hash algorithm),攻擊者能夠對每次稍微變換了hash的圖進行類似度比較,若是類似度較高,便可完成對已打標完成的圖的重定位。

重定位完成後,既能夠對已經完成的答案進行重複利用,而這種重複利用在大規模的攻擊中是很是重要的,無限彈藥在遊戲中的做用你懂的。

4.完成了以上動做之後經過用圖片搜索相應關鍵字(利用google本身的功能搞google)、其餘圖片搜索引擎(Alchemy、GRIS、Clarifai、NeuralTalk)等對圖進行搜索,並利用這些數據獲得了大量的圖片相關的子類標信息,愈來愈多的標籤信息意味着對圖片有了更多更高維度的刻畫。經過在各個網站收集相關標籤,便可獲得一個對該圖片較爲全面的描述。

 

5.利用機器學習的算法,其實就是利用Word2Vec,將兩個圖的對應關鍵字放在一個向量空間中,而後利用餘弦類似性原理,找出類似度最高的幾張圖片。(與咱們傳統的找兩個類似的文獻或同做者的思路相似)。

6.將以前的五步進行組裝。

  • 看見不曾見過的圖,感知hash計算,若是是已有答案,直接給答案。
  • 看見見過的圖,直接給答案。
  • 若是是不曾見過的,也不在數據庫內,開啓圖形引擎得到標籤信息,再扔進模型裏面獲得答案,將答案存入庫裏。
  • 循環以上步驟好比:同時出現紅酒、酒杯、酒這幾個標籤,那麼對全部得到的標籤進行類似性比對後,會取出帶有酒這個標籤的前幾個圖

 

阿里在實際的對抗中,咱們也發現有攻擊者沒法攻破第一層防護,即他們沒法正常經過,可是卻知道如何觸發第二級驗證,並嘗試經過破解第二級驗證的問題經過。

若是想要真的作好在安全和體驗間的良好平衡,須要同時在兩個方面都下功夫,才能保證總體的安全水位。

前端可信端體系的創建、強大認知問題系統的創建須要持續不斷思考和提升。咱們的每一次的變動,接入的客戶都將實時享受到更高安全等級的防禦。

 

做者:目明@阿里巴巴安所有,更多技術文章,請訪問阿里聚安全博客

相關文章
相關標籤/搜索