多要素認証を設定したら先着販売に乗り遅れた話 ― メール認証の可用性の落とし穴
多要素認証とは
皆さんは「多要素認証」(二段階認証、2FA、MFA) 設定していますか？
多要素認証とは、認証の種類を2つ以上組み合わせる仕組みです。
- 知っているもの（パスワードなど）
- 持っているもの（スマホに届くコードなど）
- 体そのもの（指紋や顔認証など）
ログイン時にこれらの2つ以上を組み合わせることで、セキュリティがより向上するような仕組みになっています。
よくあるのは「パスワード＋スマホに届くコード」です。
パスワードを入力したあと「6桁の数字を入力してください」という画面に遷移し、そこにコードを入力した、という経験をされたことがある方も多いと思います。
ここ数年、アカウント乗っ取りなどの被害が増えていることもあり、多くのサービスで導入されています。
筆者は多要素認証が設定できるサイトでは基本的にすべて設定するようにしていました。
ところが先日、とあるサイトで行われた先着販売の購入をしようとした際、思わぬ落とし穴にハマってしまったのです…
「メールが届かない…」先着販売でログインできなかった話
ある日、とあるサイトで人気商品の先着販売がありました。
事前に時間を確認し、PCの前で待機。販売開始と同時にログインを試みました。
パスワードを入力して、次の画面へ。
ここで「登録メールアドレスに認証コードを送りました」という表示が出ます。
……しかし、いくら待ってもメールが届かない。
何度も受信トレイを更新し、迷惑メールフォルダまで確認しましたが、まったく来る気配がありません。
「えっ、まさかこのタイミングで？」
時計の針はどんどん進み、すでに販売ページには「△ 残りわずか」の表示が。
ようやく数分後にメールが届いたときには、ログインの有効期限が切れており、再度やり直し。
再挑戦した頃には、販売はすでに終了していました……
「せっかく準備してたのに、挑戦権すら与えられないなんて……」
セキュリティを強化していたはずの多要素認証が、結果的に「ログインできない理由」になってしまったのです。
なぜログインできなかったのか？ ― メール認証の落とし穴
今回の問題は、多要素認証の仕組みそのものが悪いわけではありません。
一方で多要素認証の設定で「メールによる認証コードの送付」(以下「メール認証」) を指定していると、メール配信の遅延に巻き込まれるリスクがあるということがわかりました。
今回の先着販売では、二段階認証の認証コード送付メールだけでなく、販売に関する当選メール・通知メールも同時に行われていたようです。
SNS上でも「当選しました！」という投稿が相次いでおり、ちょうど同じタイミングで大量のメール送信が行われていたと推察できます。 (羨ましい！悔しい！)
メールは「送信ボタンを押した瞬間に相手に届く」ように感じますが、実際は メールサーバを通って配送 されます。アクセスが集中するとサーバが混雑し、メールが届くまでに数分かかることもあります。
結果として、認証コードの有効期限が切れる前にメールが届かない → ログインできない、という状況になってしまったのです。
サービス利用者ができること
ここまで読むと「じゃあ多要素認証は設定しないほうがいいか…」と思えてしまいそうですが、それでも設定しておいたほうが安心です。
不正ログインのリスクを下げる上で、多要素認証は非常に有効です。
特に、ECサイトのように金銭的なやり取りが発生するサービスでは、不正請求を防ぐ意味でも設定しておくのが心強いです。
一方で、メールを使った認証は遅延や届かない可能性があることを頭の片隅に置いておくと良いと思います。
多要素認証の設定でメール以外に「アプリで認証コードを生成する」や「パスキー認証」という選択肢が選べるのであれば、こちらを利用すると認証コードが届くのが遅れるリスクを減らせます。
もしメールでの多要素認証しか対応していないサイトであれば、大事なイベントや販売に挑むときには「ログインは事前に済ませておく」など、少し工夫するだけでリスクを下げられるかもしれません。
サービス開発・運用側が意識すべきこと
ここまでは利用者目線で上の内容を書いていましたが、筆者も実はソフトウェア開発部門としてセキュリティ設計などにも少しだけ関わっており、開発者視点で胃が痛い案件だな…と思っていました…。
ここからは開発者目線で、多要素認証を実装する際に気をつけたい点を書いていきます。
(興味ない方は読み飛ばしてください！)
メール認証に依存しすぎない
今回の体験から学べるのは、「セキュリティを強化するための仕組みが、場合によっては可用性を損ねてしまう」という点です。
特に「すぐにログインできること」が重要なシーンがあるサービスでは、プッシュ通知によるMFAのように配信に依存する方式は便利である一方で、遅延リスクを十分考慮すべき だと感じました。
特にメール認証には、今回記事にしたような遅延・配送失敗リスクの他にも、セキュリティ強度の問題もあります。
一般的にメール認証は他の方式と比べると強度が一段階落ちると言われており、NIST（米国標準技術研究所）などのガイドラインでも「強いMFAとしては推奨されない」と説明されています。
Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.
NIST Special Publication 800-63B 5.1.3.1 Out-of-Band Authenticators より
メール認証は一応「所有要素」に分類されますが、実際にはメールアカウントの情報さえあれば他人でもアクセスできてしまいます。SIMカードを必要とするSMS認証のように物理的な所有を保証できないため、セキュリティ強度は一段階低いと考えられています。
このような特徴から、セキュリティ業界では 「弱い所有要素」または「擬似的所有要素」 とされることが多いようです。
そのため、可能であれば
- TOTP（アプリで生成されるワンタイムコード）
- パスキー認証
といった方式を併用し、メール認証はあくまで「他の認証方式が使えなくなった際のバックアップ」として利用するのが好ましいです。
TOTPやパスキー認証のほかにも SMS認証やアプリでのプッシュ通知による多要素認証も考えられますが、これらはサービス側から「認証情報を配信する方式」になるため、メール通知と同様に配信の遅延・失敗リスクを考慮する必要があります。
メール認証しか選べない場合の工夫
とはいえ、コストや開発体制の都合で「メール認証しか選べない」という状況は現実的に存在します。
以下は実装時に考慮すべきポイントを整理しました。（ChatGPTの提案をベースにしています）
ChatGPTの提案内容
- 配送経路の分離と優先制御
- 認証コードのメールと、通知メール・キャンペーンメールを同じ配送キューで扱うと、販売開始のようなイベント時に必ず遅延が発生します。
- 認証メール専用の配送経路（SMTP サーバ）を設けるか、キューに優先度をつける設計が望ましいです。
- セキュリティ補強
- メール自体が攻撃対象になりやすいため、TLS での送信や SPF/DKIM/DMARC の適切な設定は必須です。
- 併せて「ログイン通知メール」や「異常検知通知」を導入することで、不正利用の早期発見につながります。
- 認証コードの有効期限と再送機能
- メール遅延に備えて、有効期限は数分程度の余裕を持たせることが重要です。
- さらに「コード再送」機能を設けることで、ユーザーが自分でリカバリできるようにするのが UX 的にも有効です。
- 認証のタイミングを工夫する
- すべてのログイン時に MFA を必須とすると、販売直前に入れないリスクが増します。
- 「信頼済み端末では一定期間 MFA をスキップする」や「高リスク操作（購入確定、支払い、配送先変更など）のときに MFA を求める」といった柔軟な設計が有効です。
- 利用者へのガイドライン提示
- ログイン画面やヘルプに「事前にログインを済ませておくとスムーズです」といった注意を明示するだけでも、トラブルを回避できます。
- FAQ に「メールが届かないときのチェックポイント（迷惑メールフォルダ、受信拒否設定など）」を掲載するのも効果的です。
メール認証をやむを得ず採用する際には、上記を意識したいと思います。
まとめ
今回の体験を通じて実感したのは、多要素認証はセキュリティを強化する一方で「可用性のリスク」も抱えているということです。
「安全のために設定したのに、そのせいで大事な機会を逃す」という結果になり、とても切ない気持ちになりました…。
利用者の立場での「なんで事前にログインしておかなかったんだ…」という反省と、開発者の立場での「セキュリティ周りの実装をするときは可用性も重要」という知見を記事として残しておきたいと思います。
初投稿でつたない記事ですが、サービス開発に携わる方の参考になったり、一般の利用者の方にも「こういう落とし穴があるんだ」という点が伝われば嬉しいです！
もしよければコメントやフィードバックもいただけると励みになります！
Discussion