SMS・アプリ認証では防げないフィッシング——物理セキュリティキー(FIDO2/YubiKey)で固める方法

セキュリティ中級2026年6月26日

本記事はアフィリエイト広告を含みます。

GitHubの認証情報が漏洩すれば、プライベートリポジトリへのフルアクセスに直結します。この流れはGitHubで情報漏洩が起きる5つの経路で整理しています。

では、その認証情報を盗まれないために2段階認証（2FA）を入れているとして、その2FAは本当に乗っ取りを止められるのでしょうか。SMSやアプリのワンタイムパスワードは、実はフィッシングで突破されます。本記事では、フィッシング耐性を持つ物理セキュリティキー（FIDO2/WebAuthn）への移行を、実務手順とともに解説します。

TL;DR

2FAには強度の差があります。SMS < アプリTOTP < 物理キー(FIDO2) の順で堅くなります。
SMS・TOTPは、偽サイトに誘導されると本人がコードを入力してしまうためフィッシングで突破されます。
物理キー（FIDO2/WebAuthn）はオリジン（ドメイン）に署名を束縛するため、偽サイトでは認証が成立しません。これがフィッシング耐性の正体です。
開発者・小規模事業者は GitHub / Google / 主要SaaS に物理キーを登録するのが現実的な防御線になります。
キーは2本持ちが鉄則。1本は手元、1本はバックアップとして金庫等に保管します。
定番は Yubico YubiKey 5C NFC（USB-C + NFC）。PCもスマホも1本でカバーできます。

2FAの種類と強度

ひとくちに2段階認証といっても、方式によってフィッシングへの強さがまったく違います。

2FA（2段階認証）って何？ パスワードだけでなく、もう一つの確認手段を組み合わせてログインする仕組みです。「二要素認証」「MFA（多要素認証）」とも呼ばれます。パスワードが漏れても、2つ目の認証を突破しないとログインできない——それが狙いです。

方式	仕組み	フィッシング耐性	主な弱点
SMS認証	電話番号にコードを送信	低	SIMスワップ・偽サイトへのコード入力
アプリTOTP	認証アプリが30秒ごとのコードを生成	低〜中	偽サイトへのコード入力・端末紛失
プッシュ通知承認	アプリの「承認」ボタンを押す	中	通知連打による誤承認（MFA疲労攻撃）
物理キー（FIDO2/U2F）	公開鍵暗号 + オリジン束縛	高	物理的な紛失・盗難

TOTP って何？ 認証アプリ（Google AuthenticatorやAuthyなど）が30秒ごとに生成する6桁の数字のことです。Time-based One-Time Passwordの略です。「ワンタイムパスワード」とも呼ばれます。

注意したいのは、SMSとTOTPはどちらも「画面に出たコードを人間が入力する」点です。コードを入力する相手が本物のサイトか偽サイトかを、コード自体は区別できません。ここがフィッシングに破られる根本原因です。

なぜSMS・TOTPはフィッシングで破られるのか

「SMS認証じゃダメなの?」と思う方も多いはずです。ダメ、というより「突破されうる」という表現が正確です。典型的な攻撃の流れを見ると、なぜかが分かります。

攻撃者が本物そっくりの偽ログインページ（例: github-login.example）を用意する
メールやチャットで「セキュリティ確認のため再ログインしてください」と誘導する
ユーザーが偽サイトにIDとパスワードを入力する
偽サイトはその場で本物のGitHubに同じIDとパスワードを送り込む（中継する）
本物のGitHubがSMS/TOTPコードを要求する
偽サイトが「コードを入力してください」と表示し、ユーザーが入力する
攻撃者がそのコードを本物のサイトに横流しし、ログインが成立する

このリアルタイム中継型フィッシング（AiTM：Adversary-in-the-Middle）では、ユーザーが正しいパスワードと正しいワンタイムコードを入力していても乗っ取られます。

AiTM（エー・アイ・ティー・エム）って何？ 「中間者攻撃」の一種で、攻撃者がユーザーと本物サイトの間にリアルタイムで入り込み、両方の通信を中継する手口です。ユーザーから見ると「ちゃんとログインできた」ように見えますが、攻撃者も同時にログイン済みになっています。

コードは数十秒間有効なので、その間に転送するだけで足ります。SMSもTOTPも「秘密の文字列を人間が手で渡す」設計である限り、渡す相手を間違えれば終わります。プッシュ通知承認も、通知を連打して根負けや誤タップを誘う「MFA疲労攻撃」で突破されうる弱点があります。

物理キーがフィッシングに強い理由（オリジン束縛）

物理セキュリティキーは、根本的に違う仕組みで認証します。公開鍵暗号 + オリジン束縛（origin binding）です。

仕組みを噛み砕くと、次のようになります。

キーをサービスに登録するとき、キー内部で鍵ペア（秘密鍵と公開鍵）を生成します。秘密鍵はキーの外に出ません。
このとき、鍵は「どのドメイン（オリジン）向けか」という情報と紐づけて作られます。
ログイン時、ブラウザはユーザーが今アクセスしているドメインをキーに渡します。
キーは「登録時のドメインと一致するときだけ」署名を返します。

ここが決定的な点です。偽サイト github-login.example でログインしようとしても、ブラウザがキーに渡すオリジンは github-login.example であり、github.com 向けに登録した鍵はそもそも署名を出しません。ユーザーがどれだけ騙されても、ドメインが違えば認証が成立しません。

人間の判断（このサイトは本物か?）に頼らず、ブラウザとキーがドメインの一致を機械的に検証します。これがフィッシング耐性の正体です。SMS/TOTPの「人間がコードを渡す」構造とは、守りの層がまったく異なります。

FIDO2 / WebAuthn / U2F とは

物理キーまわりの用語は混乱しやすいので整理します。

用語	位置づけ
FIDO U2F	第1世代の規格。パスワード + 物理キーの「2要素目」として使う
FIDO2	U2Fの後継となる規格群の総称。U2F相当に加えてパスワードレス認証も可能
WebAuthn	FIDO2のうち、ブラウザとサーバー間のWeb標準API。W3Cが標準化
CTAP	FIDO2のうち、ブラウザと外部キー（USB/NFC）間の通信プロトコル

ざっくり言えば、FIDO2 = WebAuthn（Web側）+ CTAP（キー側）という関係です。実務上は「FIDO2対応キーを使い、対応サイトにWebAuthnで登録する」と理解しておけば十分です。U2Fしか対応していない古いサイトでも、FIDO2キーは下位互換で使えることがほとんどです。

YubiKey 5C NFC の位置づけ

物理キーの定番が Yubico YubiKey 5C NFC です。

YubiKeyって何? 別サービス? YubiKeyは、スウェーデンのYubico社が作る物理セキュリティキーの製品名です。USBスティックのような小さなデバイスで、差し込んでタッチするだけで認証できます。月額料金はなく、デバイスを1回購入するだけです（価格は8,000〜12,000円前後が目安。Amazonで購入できます）。

開発者・小規模事業者が最初の1本を選ぶなら、YubiKey 5C NFCが扱いやすい理由は次のとおりです。

USB-C接続：近年のノートPC・MacBookに直挿しできます
NFC対応：スマートフォンにかざすだけで認証できます（モバイルでSaaSにログインする場面に有効）
FIDO2/U2F対応：GitHub・Googleをはじめ主要サービスの物理キー認証に使えます
このほかOTP・スマートカード等の複数プロトコルにも対応します

USB-CとNFCの両対応なので、PCでもスマホでも1本でカバーできるのが選ばれる理由です。USB-A端子のPCが主環境なら、同シリーズのUSB-Aモデルを選んでください。自分の端末の差込口とNFCの要否で型番が決まります。

導入手順（GitHub / Google / 主要SaaS）

登録の流れはサービスが違ってもほぼ共通です。「セキュリティ設定 → 2段階認証 → セキュリティキーを追加 → キーを挿してタッチ」という順序になります。

GitHub への登録

GitHub の Settings → Password and authentication を開く
二要素認証（2FA）が未設定なら、まず有効化する（初回はTOTPアプリの登録を求められる場合があります）
Security keys の「Register new security key」を選ぶ
キーをUSBポートに挿す（またはNFCでかざす）
キーの金属面にタッチして登録を完了する
キーに分かりやすい名前（例: yubikey-main / yubikey-backup）を付ける

Google アカウントへの登録

Google アカウントの セキュリティ → 2段階認証プロセス を開く
「セキュリティキー」または「パスキーとセキュリティキー」の項目を選ぶ
案内に従ってキーを挿し、タッチして登録する

主要SaaSへの登録

Microsoft 365、AWS（IAMユーザーのMFA）、Cloudflare、各種パスワードマネージャーなど、多くのSaaSがセキュリティキー（WebAuthn/FIDO2）に対応しています。共通して「アカウント設定 → セキュリティ/MFA → セキュリティキーを追加」の導線をたどります。

優先順位は、乗っ取られたときの被害が大きいアカウントからです。コードと認証情報の中枢であるGitHub、メールとアカウント復旧の起点になるGoogle/Microsoft、本番インフラを握るAWS・Cloudflareを先に固めます。

紛失対策（2本持ち・バックアップキー）

「物理キーを無くしたら、自分がログインできなくなるのでは?」——その不安は正しいです。物理キーの唯一にして最大の弱点は「物理的に失くす・壊す」ことです。1本しか登録していないキーを紛失すると、自分が締め出されます。

これを防ぐ鉄則は次の3つです。

キーは2本登録する：1本を普段使い（キーホルダー等）、もう1本をバックアップとして金庫・引き出し等の安全な場所に保管します。両方を同じサービスに登録しておきます。
リカバリーコードを保管する：GitHub等が発行するリカバリーコード（バックアップコード）を、印刷してオフライン保管します。キー2本を同時に失った最後の保険になります。
TOTPを完全に消さない判断：物理キーへ移行しても、当面はTOTPを予備として残す運用も現実的です。ただしTOTPはフィッシング耐性が低いことを理解した上で、あくまで復旧経路として位置づけます。

最初の1本だけで運用を始めて紛失リスクを抱えるくらいなら、最初から2本買って両方を登録しておくほうが安全です。

パスキーとの関係

近年よく聞く「パスキー（Passkey）」は、FIDO2/WebAuthnの技術をベースにしたパスワードレス認証の仕組みです。物理キーと無関係ではなく、同じ土台の上にあります。

パスキーって何? 「パスワードを使わずにログインする」新しい方式です。iPhoneのFace IDやWindowsのPIN（指紋認証など）でそのままログインできるイメージです。ただし、鍵がどこに保存されるかで種類が分かれます。

物理キーに保存するパスキー：鍵がYubiKeyのような物理デバイスから出ません。デバイスを持っていなければ認証できないため、最も堅い形です。
同期パスキー：鍵をApple/Google/Microsoftのアカウント経由でクラウド同期し、複数端末で使います。利便性は高いですが、同期先アカウントの保護強度に依存します。

どちらもオリジン束縛によるフィッシング耐性という核は共通しています。業務の中枢アカウントは物理キー（YubiKey）で固め、利便性を取りたい個人サービスは同期パスキー、といった使い分けが現実的です。物理キーへの投資は、パスキー時代になっても無駄になりません。

まとめ

観点	SMS / TOTP	物理キー（FIDO2/WebAuthn）
認証の核	人間がコードを手入力	キーがオリジンに署名を束縛
フィッシング	リアルタイム中継で突破されうる	偽ドメインでは署名が出ず不成立
主な弱点	コード横流し・SIMスワップ	物理的な紛失・盗難
推奨運用	復旧用の予備に留める	中枢アカウントの主軸に据える

GitHubの認証情報漏洩が起きても、物理キーで2FAを固めていれば、攻撃者は盗んだパスワードだけではログインできません。SMS/TOTPの「人間がコードを渡す」構造から、「ドメインが一致しなければ署名が出ない」構造へ。守りの層を一段引き上げるのが、物理セキュリティキー導入の意味です。

被害が大きいアカウント（GitHub・Google・AWS）から、キーを2本登録する。今日始められる、もっとも費用対効果の高いアカウント防御の一つです。