手機驗證碼登錄是一種常見的應用登錄方式，簡單方便，不用記憶密碼，市面上能見到的APP基本都支持這種登錄方式，很多應用還把登錄和注冊集成到了一起，注冊+登錄一氣呵成，給用戶省去了很多麻煩，頗有一機在手、天下我有的感覺，

登錄原理

手機驗證碼登錄的原理很簡單，對于一個正常的登錄流程，看下邊這張圖就夠了：

實際應用中會存在一些收不到驗證碼的情況，可能的原因如下：

• 在手機端，短信被某些軟體認為是垃圾資訊而被攔截或者洗掉，或者因為手機卡欠費導致收不到短信，

• 在應用服務端，因為程式錯誤，或者安全控制策略導致部分短信發送失敗，

• 在短信平臺或者電信運營商系統，因為黑名單、關鍵字、流量控制，或者其它某些技術原因導致發送失敗，

針對收不到短信的問題，系統中會增加重發驗證碼功能，如果多次重發還收不到，系統可以支持上行短信或者語音驗證碼的方式，這兩種方式都是短信驗證碼的變種，

• 上行短信是讓用戶將系統提前生成好的若干字符發送到系統指定的短信號碼，據此可以驗證用戶擁有指定手機的控制權，從而也就認證了用戶的身份，

  

• 語音驗證碼可以讓用戶發起，也可以在系統收到短信發送未成功的回執時主動推送，用戶手機會收到一個自動語音通話，其中包含登錄所需的驗證碼，

安全風險和應對策略

手機驗證碼的安全風險主要是被惡意利用和竊取，

因為手機驗證碼的應用十分廣泛，為了有一個更全面的認識，這里說的安全風險沒有局限在登錄這一點上，所有使用手機驗證碼的場景都可能存在，這里的應對策略主要是站在系統開發者的角度，通過各種技術方案來解決或者降低手機驗證碼的安全風險，

短信詐騙

詐騙者先獲取到用戶手機號，然后冒充金融機構、公權力部門、親朋好友，在應用中輸入用戶手機號請求驗證碼后，向用戶索要對應的手機驗證碼，用戶稍不注意可能就會造成金錢損失，

針對此類問題，系統開發者可以考慮如下一些方案：

• 在驗證碼中宣告：作業人員不會索取，打死也不要泄漏給別人，不過人在一些特殊情況下是不會理會這些警告的，

• 跟蹤用戶的常用登錄特征，比如獲取驗證碼時的設備、IP、WIFI、地域不是常用的，系統就可以馬上短信或者語音通知用戶可能存在安全風險，請謹慎操作；系統還可以直接升級安全級別要求更多的驗證方式，比如需要再次獲取驗證碼、輸入安全碼、刷取指紋、識別人臉、插入U盾等等驗證方式，

還有一種相對隱蔽的詐騙方式，詐騙者直接向用戶發送仿冒釣魚網站的地址，用戶在釣魚網站獲取驗證碼時，詐騙者拿著用戶手機號去真實網站請求驗證碼，此時用戶會收到一個真實的驗證碼，用戶在釣魚網站輸入驗證碼后，詐騙者就可以拿著這個驗證碼去真實網站使用，

針對這種情況，前邊的識別用戶常用登錄特征的方式仍然有效，此外短信平臺和電信運營商也有責任對短信內容進行把關，短信平臺需要驗證發送者的真實身份、審核短信內容，并提供動態的流量控制機制，這樣可以過濾掉絕大部分詐騙短信，

其實電信運營商是能夠識別手機位置的，如果電信運營商能夠提供一種安全的位置認證服務，也可以解決大部分驗證碼詐騙問題，比如前端提交驗證碼認證時攜帶電信運營商提供的位置標識，應用服務商可以拿著這個位置標識去找電信運營商驗證位置，當然這只是一個設想，現實中還沒有這種方法，

短信攻擊

可能有兩種場景下的短信攻擊：

• 用戶在前端不停的點擊獲取驗證碼，可能是擔心收不到驗證碼，也可能是失去了等待的耐心，也可能是惡意向別的手機號發送，

• 攻擊者直接呼叫發送驗證碼的介面，在極端的時間發送大量驗證碼請求，可能是發給某個用戶也可能是一批用戶，

此類操作首先會浪費短信資源，給應用服務商造成損失；惡意攻擊還會向無辜的用戶發送大量短信，造成騷擾攻擊，

應對這種問題，可以考慮如下一些方案：

• 增加其它驗證，

  獲取短信驗證碼之前必須先通過這些驗證，比如圖形驗證碼、滑動驗證碼、數學公式驗證碼等等，這些方式可以增加發送短信驗證碼的難度，降低人工的發送速度，盡量避免機器人自動操作，

• 對操作進行限流，

  比如現在前端常見的發送短信驗證碼倒計時，一般每次請求驗證碼后經過若干秒才能再次發送，因為如果攻擊者獲取到了發送驗證碼的服務介面，就可以擺脫前端邏輯的限制，所以后端也可以采用同樣的策略，對設備Id、手機號、IP、用戶、業務型別等等，以及它們的各種組合，進行頻率控制，應用開發者還可以根據發送結果特征來進行控制，比如空號率，如果空號太多則說明可能是機器人隨機生成的手機號，在單一頻率的限制基礎之上，還可以增加更多的時間控制，在分鐘、小時、天等時間維度上做不同的閾值限制，

• 給用戶提供一個短信退訂入口，

  用戶頻繁收到非自己主動發起的驗證碼短信時，可以提供一個退訂入口，讓用戶在短時間內關閉短信驗證碼，應用服務此時可以忽略給用戶發送驗證碼的請求，或者直接去掉發送驗證碼的功能入口，

但是這種控制要盡量以不影響用戶的正常業務操作為前提，否則就得不償失了，

• 比如圖形驗證碼的難度不要太高，畢竟大部分業務不是12306，你照搬過來可能就會弄巧成拙，

• 再比如對于限流控制，假設正常用戶一般只在一天的某些時候進行操作，不會一天24小時都在做某一件事，則可以這樣做：每個手機號每小時只能發送X次，每天只能發送Y次，這兩個數值要符合 X<Y & 24*X>>Y，

• 對于嚴重的攻擊，應該設定熔斷機制，此時不得不犧牲可用性，比如短時間涌入了大量針對不同手機號的驗證碼需求，很可能是受到了DDOS攻擊，因為資源有限，此時正常用戶的操作也會受到影響，可以依托全域限流，觸發限流時直接關閉驗證碼服務一段時間，

網路竊聽

假設用戶收到了登錄驗證碼，輸入正確后提交服務端驗證，在從手機端到服務端的傳輸程序中，會經過很多的網路設備和服務器系統，登錄提交的內容有被攔截獲取的可能，此時攻擊者就可以阻斷請求，自己拿著用戶的手機號和驗證碼去登錄，

應對這種問題，一般需要對網路傳輸內容進行加密，比如現在常用的https通信，可以保證兩端之間的傳輸內容安全，不被竊聽，對于傳輸安全，一般這樣處理也就夠了，

不過https也不是銀彈，如果有攻擊者在客戶端偷偷匯入了自己的證書，然后讓網路請求都先通過自己進行代理，再發送到目標地址，則攻擊者還是能夠獲取到請求內容，想體驗這種方式的可以使用fiddler試試，還有https證書存在錯發的可能，如果給攻擊者發放了別人的證書，此時安全傳輸也就沒什么意義了，

為了更高的安全性，傳輸內容可以在應用中加解密，客戶端對要傳輸的資料按照與服務端的約定進行加密，然后再發送到網路，攻擊者截獲后，如果沒有有效的解密手段，則可以保證資料不被竊聽，加密的重點是保證密鑰安全，不被竊取和替換，可以采用其它安全信道傳輸，甚至線下傳遞的方式，對于驗證碼這種僅做驗證的資料，還可以通過加鹽后進行慢Hash運算，攻擊者即使拿到了傳輸內容，要進行破解的難度也相當巨大，

本地竊聽

如果系統上安裝了惡意軟體或者非官方版本的軟體，特別是在盜版系統、被Root或者越獄的手機系統中，攻擊者也能比較容易的攔截并竊取短信驗證碼；同時網路竊聽中的加解密也可能失去作用，因為軟體已經不可信，在不同的操作之間有么有發生什么貓膩，很難確定，

最近幾年在移動設備上引入了一個稱為可信執行環境（簡稱TEE）的概念，獨立于作業系統，單獨的應用，單獨運行，有的甚至有單獨的處理器和存盤，外部很難進入和破解，一些關鍵的操作都封裝在這里邊，比如指紋的采集、注冊和認證，密鑰的生成和使用，著作權視頻的解碼和顯示，等等，如果把短信驗證碼的處理也放在這里邊，無疑會安全很多，不過這要解決很多通信方面的問題，收益與成本可能不成正比，在臺式機中這一技識訓所見不多，可能臺式機的環境已經有了比較成熟的安全體系，不過從移動端遷移過來難度應該也不大，

短信嗅探

短信嗅探也是一種竊聽技術，不過是通過攻擊電信網路通信的方式，

現在手機一般都使用4G、5G網路了，但是“短信嗅探”技術只針對2G網路，不法分子通過特殊設備壓制基站信號，或者選擇網路質量不佳的地方，或者使用4G偽基站欺騙手機，這會導致網路降頻，使手機的3G、4G通信降低到2G，

2G網路下，只有基站驗證手機，手機不能驗證基站，攻擊者通過架設偽基站，讓目標手機連接上來，然后就能獲取一些連接鑒權資訊，再冒充目標手機去連接真基站，連上以后撥打攻擊者的另一個手機，通過來電顯示得到目標手機號碼，

基站本身并不會用特定方向的信號與每部手機通信，而是向四周以廣播的形式發送信號，所以每部手機實際上也是可以接收到其他手機的信號，2G網路傳輸資料時沒有加密，短信內容是明文傳輸的，就可以嗅探到目標手機的短信，加之2G通訊協議是開源的，所以這件事的技術門檻并不高，

因為這種攻擊要求手機不能移動，如果基站切換就沒用了，所以攻擊一般選擇夜深人靜的時候，對于普通用戶來說，睡覺的時候可以選擇關機或者開啟飛行模式；另外開通 VoLTE ，可以讓電話和短信都是走 4G 通道，不過網路降級很難防范；或者買個能識別偽基站的手機，不過沒辦法保證百分百能夠識別；或者就只能等著移動運營商關閉2G網路了，

對于應用系統開發者，應該認識到通信通道的不安全性，必要的時候開啟雙因子驗證，除短信驗證碼外還可以使用短信上行驗證、語音通話傳輸、專用密碼驗證、常用設備系結、生物特征識別、動態選擇身份驗證方式等等多種二次驗證方法，

重放攻擊

假設某些交易服務需要通過短信驗證碼來驗證用戶的身份，如果有攻擊者截獲了交易請求報文，然后多次發送到服務端，服務端僅檢查了驗證碼是否正確，則可能實際發生多次交易，此時攻擊者都不需要解密傳輸內容，

此時應該限制驗證碼只能夠使用一次，服務端收到交易請求時首先檢查驗證碼，檢查通過后將驗證碼置位或洗掉，然后再處理交易，不管交易是否成功，驗證碼都不能再次使用，另外還應該在生成驗證碼時設定一個較短的有效期，如果用戶沒有實際提交，攻擊者也必須在有效期內才能使用，增加攻擊難度，

當然你也可以使用更通用的防重放手段，比如每次請求驗證碼都先從后端獲取一個亂數，亂數如果已經使用過則不能再次使用，亂數如果不存在也不能處理請求，當然亂數也可以在前端生成，服務端如果收到了重復的亂數則拒絕請求，但是需要防止傳輸程序中亂數不被篡改，可以通過密鑰簽名的方式，

以上就是本文主要內容，才疏學淺，如有錯漏，歡迎指正，

識訓更多架構知識，請關注公眾號 螢火架構，原創內容，轉載請注明出處，

標籤：架構設計

上一篇：連阿里大神都畏懼的高可用風險

下一篇：微服務架構 | 3.3 Apache Zookeeper 注冊中心