SMS認証はもう「穴だらけ」だ。今すぐFIDO2への移行を検討すべき理由
「MFAを導入しているから大丈夫」。そう油断しているエンジニアほど、インシデント発生時に顔面蒼白になる。
現場で多くの不正アクセスを見てきたが、SMSや音声によるワンタイムパスワード（OTP）は、今の攻撃者にとっては「鍵のかかっていない玄関」に等しい。なぜなら、彼らは通信キャリアの脆弱性を突く「SIMスワップ」や、巧妙に偽サイトへ誘導する「AiTM（Adversary-in-the-Middle）攻撃」を日常的に行っているからだ。
今日は、なぜSMS認証が崩壊しているのか、そして私たちが明日から導入すべき「フィッシング耐性のある認証」への移行戦略について、泥臭い現実を交えて解説する。
—
1. なぜSMS/音声OTPが「無力」なのか
SIMスワップの恐怖
攻撃者は、ソーシャルエンジニアリングやダークウェブで入手した個人情報を悪用し、標的の電話番号を自分のSIMカードへと書き換えさせる（SIMスワップ）。これが成功すれば、あなたのアプリが送るOTPは、攻撃者の端末に直接届く。ユーザーがスマホを握りしめていても、認証は突破される。
AiTM（中間者攻撃）の進化
最近のフィッシングサイトは、ユーザーが入力したIDとパスワードを裏で即座に正規のサイトへ流し込み、正規サイトから送られてきたOTP入力画面を「リアルタイム」でユーザーに提示する。ユーザーがOTPを入力した瞬間、セッションクッキーを盗み出される。これには、どんなに長いSMSコードでも太刀打ちできない。
—
2. 唯一の希望：FIDO2 / WebAuthn
この状況を覆す唯一の解が、FIDO2だ。これは「公開鍵暗号方式」を利用しており、サーバー側には公開鍵のみを保存する。
最大の特徴は、「オリジン（ドメイン）の検証」だ。フィッシングサイトでいくら認証を試みても、ブラウザが「このドメインは本来のサイトと違う」と検知し、認証リクエストを拒否する。これにより、AiTM攻撃は根本から成立しなくなる。
—
3. 実践：Python (Flask) でのWebAuthn実装のヒント
FIDO2の実装は一見難解だが、ライブラリを活用すれば実務レベルに落とし込める。ここでは、webauthnライブラリを使った認証フローの骨子を示す。
要件: pip install webauthn
from webauthn import generate_authentication_options, verify_authentication_response
1. 認証チャレンジの生成（サーバーサイド）
def get_auth_options(user_credential_id):
# ここで生成されたチャレンジはセッションに保存し、レスポンス検証時に照合する
options = generate_authentication_options(
rp_id=”your-secure-app.com”,
allow_credentials=[{“id”: user_credential_id}],
user_verification=”required” # 指紋認証等の生体認証を強制
)
return options
2. 認証レスポンスの検証（サーバーサイド）
def verify_auth(response_data, expected_challenge, credential_public_key):
# 攻撃者が偽サイトで認証しようとしても、ここでドメイン不一致が弾かれる
result = verify_authentication_response(
credential=response_data,
expected_challenge=expected_challenge,
expected_rp_id=”your-secure-app.com”,
expected_origin=”https://your-secure-app.com”,
credential_public_key=credential_public_key
)
return result.verified
開発時のポイント
user_verification="required"を必ず指定せよ。これにより、デバイス側で生体認証（TouchID/FaceIDなど）が強制され、盗まれたデバイスを物理的に操作されるリスクも排除できる。expected_originの検証は妥協するな。ここがFIDO2の心臓部だ。
—
4. インフラ・設定で防ぐ「盲点」
アプリの実装だけでなく、WAFやIAMの設定でも防御を固める必要がある。
Nginxでのセキュリティヘッダー設定
フィッシングサイトへのリダイレクトや、悪意あるスクリプトの実行を阻止するために、以下のヘッダーを付与しておくことは最低限の礼儀だ。
信頼できるドメイン以外からの埋め込みを禁止
add_header Content-Security-Policy “default-src ‘self’; frame-ancestors ‘none’;”;
リファラー情報を絞り、情報漏洩を防ぐ
add_header Referrer-Policy “strict-origin-when-cross-origin”;
クラウドIAMのガードレール
AWSやGCPを使用している場合、「MFAなしでのルートユーザー操作」をSNS通知で即座に検知するアラートを設定しておけ。また、APIキーの発行には必ずIP制限をかけ、万が一の漏洩時にも「どこからでも叩ける」状態を回避するのが鉄則だ。
—
結論：セキュリティは「コスト」ではなく「信頼の投資」だ
「SMS認証で十分」という甘い判断が、顧客の信頼と企業の資産を吹き飛ばす。移行コストは確かにかかるが、インシデント発生時の社会的損失と比較すれば、それは微々たるものだ。
まずは、社内の管理画面や開発者向けツールから、ハードウェアセキュリティキーやパスキー（FIDO2）の導入を始めてほしい。それが、現代のエンジニアとして持つべき「最低限の誠実さ」だと私は信じている。
もし実装で詰まったら、ドキュメントの奥底にある仕様書を読み込め。そこに、攻撃者との知恵比べに勝つための全てが書かれている。健闘を祈る。
コメント