有了雙因素驗證（2FA），就算密碼外洩，光憑那個也進不來。本文整理它與常被混淆的兩步驟驗證的差異，以及各方式的強弱（不會寫出攻擊手法）。
「兩個因素」與「兩個步驟」的差異
這兩個詞看起來很像，但只要抓住目的就很簡單。驗證的「因素」分為以下三個類別：
**雙因素驗證（2FA）**會混合兩種不同的類別（例如：密碼＝知識＋手機的驗證器 App＝持有）。重點在於：如果其中一個被攻破，另一個不同類別仍然有效，攻擊者就無法闖入。
相對地，兩步驟驗證（2SV）只表示「確認兩次」，兩個步驟即使是同一類別也算成立（密碼＋安全提示問題是兩個步驟，但不是兩個因素）。所以若真的想要更強，關鍵就是混合不同的類別。
方式的強弱：取決於假網站能否竊取你輸入的內容
即使開了 2FA，方式不同，強度也會大不相同。決定性的因素在於：你會不會不小心把那個「證明」交給假網站。
強 ── 通行金鑰 / 實體金鑰（FIDO2）
簽章繫結在網域上——從結構上就無法對假網站出示（抗釣魚）
中 ── 驗證器 App（TOTP）
比簡訊強，但驗證碼要由人來讀——所以能被交給假網站
弱 ── 簡訊 / 郵件的驗證碼
驗證碼可能遭釣魚；SMS 也面臨手機號碼劫持
弱：簡訊 / 郵件的驗證碼
- 驗證碼要由人來讀取並輸入＝可以直接交給假網站
- SIM 卡交換針對手機號碼上的 SMS 或語音接收。郵件驗證碼依賴信箱及其復原機制的保護；兩種手動輸入的驗證碼都可能遭釣魚。
- 即便如此，仍明顯比只有密碼強（遠比什麼都沒有好）
強：通行金鑰 / 實體金鑰（FIDO2）
- 簽章繫結在網站的網域上＝不可能對假網站出示
- 單獨以通行金鑰或安全金鑰實作 MFA 時，服務必須要求並驗證 PIN、生物辨識等使用者驗證。安全金鑰也能與密碼搭配；僅觸碰以確認人在場不等於第二種因素。
- 驗證器 App（TOTP）介於兩者之間——比簡訊強，但仍能對假網站出示
2FA、兩步驟驗證、MFA、OTP 與通行金鑰的區別
相似的用語之所以很多，是因為指「概念」的詞和指「方式」的詞混在一起。
| 用語 | 意思 | 例子 |
|---|---|---|
| 雙因素驗證（2FA） | 組合兩種不同類別證明的概念 | 密碼＋驗證器 App 的驗證碼 |
| 多因素驗證（MFA） | 組合兩種以上不同類別證明的概念（包含 2FA） | 簽章綁定網域；要求使用者驗證時使用 PIN 或生物辨識 |
| 兩步驟驗證（2SV） | 確認兩次（兩者可以是同一類別） | 密碼＋安全提示問題 |
| 一次性密碼（OTP） | 常被當作第二個證明的單次驗證碼 | 驗證器 App、簡訊或電子郵件的驗證碼 |
| 通行金鑰 | 用裝置內的私鑰簽章的登入方式 | 用指紋或臉部解鎖來登入 |
2FA 與 MFA 說的是「要滿足什麼」；OTP 與通行金鑰說的是「怎麼滿足」。驗證碼請見什麼是一次性密碼（OTP），簽章請見什麼是通行金鑰。即使服務畫面上寫的是「兩步驟驗證」，背後常常是「密碼＋驗證器 App」這類 2FA，所以請依實際的方式來判斷。
2FA 能擋下多少
微軟的研究人員在 2023 年分析該公司雲端使用者的研究發現，啟用 MFA 的帳號整體遭入侵的風險降低了 99.22%，即使是在憑證已外洩的情況下也降低了 98.56%。不論方式為何，光是開啟 2FA，就能擋下大多數因密碼重複使用或外洩造成的帳號被盜。
不過，仍有 2FA 擋不下的情況。
- 輸入到假網站：在假網站輸入的簡訊與驗證器 App 驗證碼，會被中繼到真網站。通行金鑰與實體金鑰可以防止這種情況
- 脆弱的復原方式：如果帳號只需簡訊或登錄的電子郵件就能復原，那就會成為入口
- 沒有 2FA 的帳號：如果攻擊者經由沒有 2FA 的公司電子郵件或第三方服務帳號闖入，你的其他防禦也幫不上忙
公開事故：區分原因評估與建議措施
營運集團在2019年8月1日公告中認為，使用非法取得的 ID 與密碼清單進行攻擊的可能性較高。這是公司當時的評估，不代表所有攻擊路徑都已確定。 同一公告表示，當時未發現外部 ID 連結、密碼提醒或人工聊天重設等功能直接造成未授權存取的案例。 截至2019年7月31日17時，認定808人、38,615,473日圓損失，包含未授權儲值與使用。這是8月1日公告的時點資料，不是其宣稱的最終總數。 7pay 盜刷事件（2019）.
此後，越來越多服務不再把 2FA 交給使用者自行決定，而是強制要求。GitHub 自 2023 年 3 月起，逐步要求貢獻程式碼的使用者啟用 2FA（設定方式請見設定 GitHub 雙因素驗證）。本站在 2026 年 8 月分類日本公開的主要事件時發現，從正規憑證——委外廠商的 Microsoft 365、公司電子郵件、GitHub 憑證——開始的事件，比從遭利用的漏洞開始的還多（2026 年日本的外洩事件是從哪裡進來的）。
如何檢查自己的帳號
決定順序
先從電子郵件與密碼管理器開始，因為兩者都會被用來重設或管理你的其他帳號。接著是網域、雲端與 GitHub，然後是銀行、證券與支付。
確認每個帳號的 2FA 方式
在安全性設定中，查看 2FA 是否已開啟、使用哪種方式。如果是簡訊或電子郵件驗證碼，就新增驗證器 App 或通行金鑰並設為優先。各方式的比較請見如何正確挑選多因素認證（MFA）。
準備復原碼與第二種方式
把復原碼存放在手機以外的地方，例如密碼管理器中。也登錄第二種方式，例如備用的通行金鑰或實體金鑰。
檢視復原用的電子郵件與電話號碼
確認登錄的復原用電子郵件地址與電話號碼仍然是你的，且復原用的電子郵件帳號本身也開了 2FA。想確認密碼是否已經外洩，請見如何確認密碼是否已外洩。
如果你管理他人的帳號，就強制要求 2FA
公司電子郵件、GitHub 組織與雲端管理主控台，不要讓 2FA 成為選項，而是在組織設定中強制要求。請管理員帳號使用通行金鑰或實體金鑰。
本站的觀點：先開起來，再往『交不出去』的方式移動
2FA 最常見的失敗，是想太多「哪個最強」而結果一個都沒開。優先順序很清楚：先在每個帳戶開啟某種 2FA，再把最重要的帳戶（電子郵件、網域、支付）遷移到無法交給釣魚網站的方式（通行金鑰）。
本站不把「靠小心來識破假網站」算作一種防禦策略。與其依賴人的注意力，不如靠那些從結構上就無法把證明交給假網站的方式。
出處（一手資料）
- NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」（2025 年 7 月）— pages.nist.gov（驗證因素、抗釣魚、電話網路方式受限制）
- Meyer 等「How effective is multifactor authentication at deterring cyberattacks?」（Microsoft，2023 年）— arxiv.org（MFA 使遭入侵風險降低 99.22%，憑證外洩時降低 98.56%）
- CISA「Implementing Phishing-Resistant MFA」（2022 年 10 月）— cisa.gov（PDF）（MFA 形式由強到弱的排序、鎖定簡訊的 SIM 交換）
- GitHub Docs「About mandatory two-factor authentication」— docs.github.com（自 2023 年 3 月起逐步強制）
- 營運集團關於服務終止、調查與應對的公告 (2019-08-01) — 7andi.com
接下來閱讀
- GitHub 設定：如何設定 GitHub 雙因素驗證
- 術語：什麼是一次性密碼（OTP）（驗證器 App 的驗證碼如何運作・TOTP/HOTP/簡訊）／ 什麼是通行金鑰（無法交給假網站的最強方式）
- 術語：什麼是釣魚（理解瞄準 2FA 的中間人 AiTM）
- 入門：如何正確挑選多因素認證（MFA）（在實務中選定方式）
- 案例：7pay 盜刷事件（2019）