雙重認證如何運作?

從TOTP演算法到FIDO2加密技術——清晰解釋每種雙重認證類型如何生成驗證碼、驗證用戶身份,以及保護帳戶免受攻擊者侵害。

Diagram showing how two-factor authentication works with TOTP codes and cryptography
1TOTP驗證碼

驗證應用程式如何生成一次性驗證碼

驗證應用程式使用RFC 6238所定義的基於時間的一次性密碼(TOTP)演算法。整個過程從您在設定雙重認證時掃描QR碼開始。該QR碼包含一個密鑰——一串隨機位元組,由服務提供商(如Google或Facebook)與您的驗證應用程式共同持有。這個共用密鑰在雙方安全儲存,初始設定後不會再次傳輸。

每隔30秒,您的驗證應用程式會執行HMAC-SHA1加密運算,將共用密鑰與當前Unix時間戳(以30秒為間隔劃分)結合。運算結果經過雜湊處理並截斷,生成您所看到的六位數驗證碼。與此同時,伺服器執行完全相同的計算。當您提交驗證碼時,伺服器將您輸入的內容與其計算結果進行比對——若吻合,驗證即成功。由於驗證碼由時間和密鑰衍生,每30秒便會更新,且不可重複使用。

這種設計具有關鍵的安全特性:密鑰從不離開初始設定過程。您的驗證應用程式完全離線生成驗證碼——無需網絡連接,且在您於登入時提交驗證碼之前不會與伺服器通訊。這就是為何驗證應用程式在飛行模式下也能正常運作,以及為何攔截您的網絡流量無法暴露底層密鑰或未來的驗證碼。

  • 共用密鑰:在掃描QR碼時建立的隨機金鑰——之後不再傳輸
  • HMAC-SHA1:將密鑰與當前時間 ↗戳結合以生成每個驗證碼
  • 30秒週期:驗證碼每30秒自動失效並更新
  • 離線生成:無需網絡連接——驗證碼在飛行模式下亦可使用
  • 不可重複使用:每個驗證碼只能使用一次,驗證後立即失效
  • 伺服器端驗證:伺服器執行相同計算並比對結果
了解TOTP與HOTP標準的分別 →
TOTP algorithm diagram showing how 30-second codes are generated
2短訊及推送通知

短訊驗證碼及推送通知的運作原理

基於短訊的雙重認證採用截然不同的方式。當您嘗試登入時,服務提供商在其伺服器上生成一個隨機驗證碼,並透過電話網絡的短訊服務發送至您已登記的電話號碼。您收到短訊後讀取驗證碼並輸入登入表單。伺服器驗證您所輸入的驗證碼是否與發送的一致,以及是否已過期(通常在5至10分鐘內有效)。

短訊雙重認證的弱點在於電話網絡本身。電信網絡所使用的SS7協議是在安全意識普及之前的年代所設計,其信任模型允許全球網絡中的任何運營商為任意號碼請求通話及短訊轉發。擁有電信基礎設施訪問權限的複雜攻擊者可以無聲攔截短訊。更常見的是,SIM卡調換攻擊利用運營商的客戶服務流程,將受害者的號碼轉移至攻擊者控制的新SIM卡,此後所有通話和短訊均發送至攻擊者處。

Duo Security及部分銀行應用程式所採用的推送通知雙重認證,會向您已登記的設備發送登入審批請求作為推送通知。您查看請求詳情(登入時間、地點、設備),然後點擊批准或拒絕。這比短訊更為安全,因為它依賴iOS或Android的推送通知基礎設施,而非電話網絡。然而,此方式需要網絡連接,且容易受到「推送疲勞」攻擊——犯罪分子反覆發送審批請求,希望用戶不慎批准其中一個。

  • 短訊生成:伺服器創建隨機驗證碼,透過電信網絡發送至您的電話
  • 短訊漏洞:SS7協議缺陷及SIM卡調換可將您的短訊重定向至攻擊者
  • 推送通知:使用iOS/Android推送基礎設施,而非電話網絡
  • 推送情境:顯示登入地點和設備詳情,讓您核實合法性
  • 推送疲勞:攻擊者大量發送審批請求,希望用戶誤觸批准——務必先核實
  • 短訊最佳做法:在有選擇的情況下,升級使用驗證應用程式
了解短訊雙重認證的所有破解方式 →
SMS 2FA and push notification authentication flow
3硬件安全金鑰

硬件安全金鑰的運作原理:FIDO2與WebAuthn

硬件安全金鑰透過FIDO2標準及其瀏覽器整合協議WebAuthn使用公鑰加密技術。當您向某服務登記硬件金鑰時,金鑰會生成一對唯一的加密金鑰:公鑰與服務共享,私鑰則永不離開硬件設備。私鑰儲存於安全元件中——金鑰內部的防篡改芯片,即使對設備進行物理訪問,提取私鑰亦幾乎不可能。

登入時,伺服器向您的瀏覽器發送一個挑戰——一段隨機數據——瀏覽器將其轉發至硬件金鑰。金鑰提示您觸摸它(或透過NFC感應),然後用私鑰對挑戰進行簽名。瀏覽器將簽名發回伺服器,伺服器使用您已登記的公鑰進行驗證。關鍵在於,金鑰在簽名之前亦會驗證網站的域名。這種域名綁定意味著,即使釣魚網站完美仿冒真實的登入頁面,金鑰也不會對您進行驗證——因為域名與已登記的服務不符。

這種防釣魚能力正是硬件金鑰有別於所有其他雙重認證形式的地方。TOTP驗證碼和推送通知可被複雜的釣魚代理在實時中轉發,但硬件金鑰的域名驗證無法被欺騙。這就是為何注重安全的組織——包括Google(為所有員工發放金鑰,並報告此後零成功釣魚攻擊)——將硬件金鑰視為保護高價值帳戶的必要工具。

  • 金鑰對生成:設備在登記時為每個服務創建唯一的公鑰/私鑰對
  • 私鑰安全:儲存於防篡改安全元件中——從不傳輸或可提取
  • 挑戰-回應:伺服器發送隨機挑戰;金鑰以私鑰簽名作出回應
  • 域名綁定:金鑰在簽名前驗證確切的網站域名——釣魚網站驗證失敗
  • 需要物理觸碰:要求用戶存在(觸摸金鑰),防止遠程攻擊
  • 防釣魚:無論釣魚網站看起來多麼逼真,均無法在假網站上進行驗證
深入了解硬件安全金鑰的一切 →
FIDO2 WebAuthn hardware security key authentication flow
4未來趨勢:通行密鑰

通行密鑰:下一代驗證技術的運作方式

通行密鑰實現了與硬件安全金鑰相同的FIDO2公鑰加密技術,但使用您設備的內置安全硬件——iPhone和Mac上的安全隔區(Secure Enclave),或Windows設備上的受信任平台模組(TPM)。私鑰綁定於您的設備,並由您的生物特徵(Face ID、Touch ID或指紋)保護。當您登入支持通行密鑰的服務時,您的設備驗證您的生物特徵,然後對伺服器的挑戰進行簽名,完成驗證,整個過程無需輸入密碼。

從技術角度來看,通行密鑰比傳統雙重認證更為優雅,因為它將雙因素要求壓縮為單一操作,在內部自動滿足兩個因素:您擁有的東西(包含加密金鑰的設備)和您本身的特徵(解鎖它的生物特徵)。用戶體驗感覺只需一個步驟,但安全架構自動實現了雙重認證。

通行密鑰亦解決了同步的難題。與硬件金鑰不同,通行密鑰可透過iCloud鑰匙圈(Apple設備)或Google密碼管理員(Android/Chrome)跨設備同步。這意味著您在Google上的通行密鑰可同時在iPhone、MacBook和iPad上使用,無需額外設定。然而,同步也意味著入侵您的雲端帳戶可能會暴露您的通行密鑰——因此,使用同步通行密鑰時,您的Apple ID或Google帳戶安全性至關重要。

  • 設備端加密:私鑰儲存於設備的硬件安全芯片中
  • 生物特徵解鎖:Face ID、Touch ID或指紋解鎖金鑰以進行簽名
  • 單一操作包含兩個因素:設備持有與生物特徵無縫結合
  • 跨設備同步:通行密鑰透過iCloud鑰匙圈或Google密碼管理員同步
  • 防釣魚:繼承FIDO2的域名綁定特性——無法在假網站上進行驗證
  • 廣泛支持:Apple、Google、Microsoft及數千項服務現已接受通行密鑰
閱讀通行密鑰完整指南 →
Passkeys using biometric authentication as 2FA replacement

現在您已了解雙重認證——是時候付諸實行

您已了解驗證應用程式、短訊驗證碼及硬件金鑰的運作原理。現在比較您的選擇,為您的帳戶設置最佳的雙重認證。

Related VPN Articles