KDDIやBiglobeなど（以下ISP）でメールアドレスのID/PASSWORDが流出した件について、技術的背景と構造的問題を整理する。
1. 何が起きたのか
KDDIが提供するメール基盤に不正アクセスがあり、
- メールアドレス
- メール用パスワード
が大量に流出した。
さらに問題を大きくしたのは、メールのID/PASSWORDがISP管理画面のID/PASSWORDと共通であった事実である。
ただし、ISP管理画面側では電話番号認証などの追加要素が設定されるケースが多く、管理画面が突破される可能性は低いと考えられる。
2. ISP側の怠慢：パスワードをハッシュ化していなかった可能性
今回の流出で最も深刻なのは、パスワードがハッシュ化されていなかった可能性が高い点である。
通常、パスワードは
- 不可逆ハッシュ（PBKDF2、bcrypt、Argon2など）
- ソルト付き
で保存するのが当然である。
ハッシュ化されていれば、ソルトが流出していない限り、パスワードがそのまま漏洩することはない。
なぜハッシュ化していなかったのか
背景にはISPビジネスの歴史がある。
- ISPは1990年代から事業を開始
- 当時は「パスワード復活（再発行）」が必要だった
- 復号可能な形式で保存することが一般的だった
つまり、当時はハッシュ化していないことが悪ではなかった。
しかし、ここ20年は状況が完全に変化した。
- ハッシュ化は当然
- 復号可能な保存はNG
- セキュリティ基準は大幅に向上
にもかかわらず、ISPが古い仕組みを改修してこなかったのは怠慢である。
3. しかし、問題は単純ではない
今回の問題は「ハッシュ化していなかったISPが悪い」で終わる話ではない。
構造的な事情が存在する。
ISP契約するとメールアドレスが発行される
現在でもISP契約するとメールアドレスが発行される。
これは1990年代の名残である。
当時はメールアドレスを持つこと自体が難しく、
- ISP提供のメールアドレスを使う
- ISPのIDとメールIDを共通化する
という設計はユーザー視点では合理的であった。
Gmail登場は2004年であり、それ以前はISPメールが主流であった。
4. 時代の変化：MFA必須・パスキー必須の世界
しかし、時代は変化した。
- 総当たり攻撃の高度化
- パスワードリスト攻撃の増加
- ID/PASSWORDだけでは突破されやすい
そのため、
- MFA（多要素認証）
- パスキー（FIDO2/WebAuthn）
が必須となった。
ISP管理画面に電話番号認証が導入されたのは、この流れの中で自然な対応である。
5. しかし「メール」は別問題：IMAP/POP3/SMTPは知識値しか使えない
ここが最大の構造的問題である。
IMAP/POP3/SMTPは知識値（ID/PASSWORD）以外の認証方式を想定していない
IMAP/POP3/SMTPは1990年代に設計されたプロトコルであり、
ID/PASSWORD認証が前提である。
MFAやパスキーを組み込む余地はほぼ存在しない。
なぜMFAやパスキーを実装できないのか
理由はプロトコル仕様そのものにある。
- IMAP/POP3/SMTPはステートフル
- 認証フローが単純で拡張しにくい
- クライアント（iPhoneメール、Outlook）が標準仕様しか実装していない
そのため、
知識値以外の認証方式を現実的に採用できない。
大手メールサービスは「独自拡張」で対応している
Yahoo、iCloud、Gmail、Hotmailなどは、
- 独自のOAuth認証
- 独自のMFA/パスキー連携
を実装している。
iPhoneメールやOutlookで「メールプロバイダ選択」が出てくるのは、この独自拡張があるためである。
しかし、
KDDIやBiglobeなどのISPが世界的にマイナーであるため、独自拡張が採用される可能性はほぼない。
結果として、
ISPメールは今後もID/PASSWORD認証を使い続けるしかない
という構造的問題が存在する。
6. ID共通化のリスク
ISP管理画面のIDとメールIDを共通化すると、
- 管理画面は電話番号認証などで守られる
- メール側は知識値のみで守られる
という非対称な状態が生じる。
メール側が突破されると、
管理画面のID/PASSWORDも漏洩する
というリスクが発生する。
7. では、ISPはどうすればよいのか（現実的な解決策）
結論として、IMAP/POP3/SMTPが知識値しか使えない以上、
ISPメールを安全に運用することは構造的に難しい。
解決策1：ISPメールの発行をやめる
最も安全なのは、
- ISPメールの発行を中止
- Webメールのみ提供
- WebメールにはMFA・パスキーを実装
という方法である。
解決策2：専用ネイティブアプリを提供する
しかし、
- Outlookユーザー
- iPhoneメールユーザー
から強い反発が出る。
そこで、
WebメールをWebViewでラップした専用ネイティブアプリを提供する
という方法が現実的である。
Gmailアプリのような形である。
これにより、
- MFA/パスキー対応
- Outlook/iPhoneメールを使わない
- ユーザー体験を損なわない
というバランスが取れる。
解決策3：ISPメール提供を段階的に終了する
最終的には、
ISPメール提供を終了する
という選択肢もある。
ただし反発が大きいため、
専用アプリ提供 → 段階的終了
という流れが現実的である。
まとめ
今回のISPメール流出問題は、
- ハッシュ化していなかった怠慢
- 1990年代から続く歴史的負債
- IMAP/POP3/SMTPの仕様的限界
- ID共通化による構造的リスク
が複合的に重なった結果である。
特に、
IMAP/POP3/SMTPが知識値以外の認証を現実的にサポートできない
という仕様上の限界は、今後もISPメールに付きまとう問題である。
ISPが本気で安全性を高めるなら、
- Webメール＋MFA/パスキー
- 専用ネイティブアプリ
- ISPメールの段階的終了
といった抜本的な対策が必要である。