SMS認証を廃止しパスキーへ！NISTが制限する脆弱性と中継フィッシングの罠

• 事実と背景：NIST SP 800-63B第4版でもSMS認証は『制限付き』とされ、SIMスワップや通信傍受による突破リスクが改めて警告されている。
• 技術的変革：認証アプリのTOTPは通信不要で安全だが、中継フィッシング（AiTM）に対してはSMS同様に構造的な脆弱性を抱えている。
• 現場への影響：開発者は認証の第一選択肢をパスキーとし、移行期には認証アプリの推奨とバックアップコードの確実な保存をユーザーに促すべきだ。

海外出張や旅行の初日、現地のプリペイドSIMに差し替えた瞬間に訪れる絶望を想像してほしい。銀行アプリや社内ツールにログインしようとすると、画面には無慈悲にも「SMSで確認コードを送信しました」の文字が表示される。手元にあるのは、机の上に置かれた日本のSIMカード。電波が届かないのだから、コードが届くはずもない。この「本人なのにシステムから締め出される」という可用性の欠如は、我々開発者が設計時に見落としがちな極めて生々しいバグである。

SMS認証が抱えるセキュリティリスクは、単なる可用性の問題に留まらない。第一の脅威は「SIMスワップ」だ。2024年、日本国内でも偽造マイナンバーカードを用いて携帯ショップの本人確認を突破し、SIMカードを再発行させてSMS認証を乗っ取る事件が多発した。標的となったのは、氏名や住所などの個人情報が公開されやすい地方議員らであった。第二の脅威は「電話網（SS7）の傍受」である。SMSはエンドツーエンドで暗号化されておらず、通信事業者間の古い信号プロトコルであるSS7の脆弱性を突かれれば、国家レベルの攻撃者や高度なハッカーによって通信を横取りされるリスクが常につきまとう。

米国NISTのデジタルアイデンティティガイドライン「SP 800-63B」では、第3版に続き2025年に改訂された第4版でも、電話網（SMS・音声）を用いた認証を「制限付き（restricted）」と位置づけている。これは「使うな」という意味ではないが、組織がリスクを許容し、SIM変更の監視や10分以内の有効期限設定など、厳格な運用を求めるものだ。我々エンジニアは、SMS認証がもはや「安全な多要素認証（MFA）」ではなく、「パスワード単体よりはマシな、リスクを孕んだレガシーインフラ」であることを自覚しなければならない。

一方で、同じ海外の地でも、Google Authenticatorなどの認証アプリは機内モードですら正確に6桁の数字を吐き出し続ける。なぜ通信もしていないのに、サーバーとスマホで同じ数字が同期するのか。その答えは、RFC 6238で定義されたTOTP（Time-based One-Time Password）の極めて美しい数学的調和にある。

TOTPの仕組みは驚くほどシンプルだ。登録時にQRコードを介して「共有シークレット」を一度だけスマホに保存する。以降は、スマホ側で「共有シークレット」と「現在時刻を30秒で割った整数（エポックタイム）」をインプットとし、HMAC-SHA1を計算する。そのハッシュ値から特定の4バイトを切り出し、10進数6桁に丸めるだけだ。Pythonの標準ライブラリであるhmacやhashlibを用いれば、わずか20行足らずで実装できる。サーバー側も全く同じ計算を行い、クライアントから送られてきた値と一致するかを検証する。ネットワーク遅延や端末の時計のズレを考慮し、前後1ステップ（前後30秒）の猶予を持たせるのが一般的だ。

しかし、この美しく完成されたTOTPすら、現代の攻撃手法の前には無力化する。それが「Adversary-in-the-Middle（AiTM：中継フィッシング）」だ。Evilginxなどのプロキシツールを用いた攻撃では、攻撃者が本物のサイトとユーザーの間に偽サイトを挟み込む。ユーザーがIDとパスワード、そして認証アプリが表示した「正しい6桁」を偽サイトに入力すると、偽サイトはそれをリアルタイムで本物のサイトに転送する。本物のサイトは認証を成功させ、セッションクッキーを発行するが、偽サイトはそのクッキーを奪取する。結果として、ユーザーがどれだけ正確にTOTPを入力しようとも、セッションそのものが乗っ取られてしまうのだ。TOTPの致命的な弱点は、「その6桁のコードが、どのドメインに対して入力されているか」をコード自身が関知できない点にある。

では、我々エンジニアはこの「中継フィッシング」というデッドロックからどうやって抜け出すべきなのか。その唯一の構造的解決策が「パスキー（FIDO2/WebAuthn）」である。各認証方式の特性を比較すると、その差は歴然だ。

パスキーがTOTPやSMSと決定的に異なるのは、認証プロセスに「オリジン（ドメイン）の検証」が組み込まれている点だ。パスキーは、公開鍵暗号方式を用いてデバイス内の秘密鍵で署名を作成する。この際、ブラウザやOSが現在アクセスしているドメイン（RP ID）を厳格にチェックし、署名対象に含める。仮にユーザーが偽サイトに騙されてアクセスしても、デバイスは本物のサイト用の鍵を呼び出さない。また、仮に署名が作られたとしても、ドメインの不一致によりサーバー側で検証エラーとなる。中継フィッシングが構造的に成立しないのだ。

我々開発者が明日から取り組むべきアクションは明確だ。新規プロダクトの設計においては、MFAの第一選択肢として「パスキー」をデフォルトに据えること。既存システムにおいては、SMS認証からTOTP（認証アプリ）への移行を促しつつ、最終的なゴールとしてパスキーの導入ロードマップを策定することだ。また、TOTPを採用する場合は、端末紛失時のアカウントロックを防ぐため、バックアップコードの生成と安全な保存（パスワードマネージャーの推奨など）をユーザーに徹底させる設計が不可欠である。

最後に、我々自身に問いかけたい。ユーザーの利便性を犠牲にし、フィッシング耐性もない「6桁の数字を打ち込ませる儀式」を、我々はいつまでシステムに実装し続けるのだろうか。レガシーな認証方式に固執することは、技術的負債を抱えるだけでなく、ユーザーを危険に晒し続けることに他ならない。今こそ、パスキーというモダンなセキュリティ標準へ舵を切る決断の時だ。