速報

Firefoxが不正な証明書への対策を追加!OneCRL配信が届かない端末も更新を確認

CATEGORY

ゆうIDが2段階認証を必須化!不正ログインの公表から見直す会員サイトの守り方

※本ページのリンクにはプロモーションが含まれています。

使い回された認証情報の遮断と追加認証、住所録の保護を表す灰色背景のフラットな概念イラスト

この記事のポイント

対象
ゆうID、ゆうゆうポイント
影響
外部で漏えいしたID・パスワードによる不正ログインと会員情報・住所録情報の閲覧可能性。
推奨対応
公式案内に従って固有パスワード、2段階認証、パスキーを確認。不審な連絡を避け、運営側は複数の認証経路と復旧手続きを点検。
公表日

目次

日本郵政は2026年10月19日、ゆうIDで第三者による不正ログインが判明し、会員情報が閲覧された可能性を公表しました。日本郵便は翌20日から、ゆうIDへのログイン時の2段階認証を必須化すると案内しています。外部で流出したID・パスワードが、自社サービスの正規ログイン経路へ持ち込まれる問題です。

本稿は10月20日に公式発表と技術資料を確認したものです。事件の検知日、初回公表日、認証変更の適用日を区別します。前半は公表事実、後半の会員サイトへの適用案と検証例は本サイトの提案です。AI悪用の事実や、未公表の侵入経路を補って説明しません。

出典:日本郵政:第三者による不正利用および会員情報漏えいの可能性について

スポンサーリンク

249件という数字と情報閲覧の可能性を区別する

日本郵政は10月15日にゆうゆうポイントサイトで不審なアクセスを検知し、16日から同サイトを停止したと説明しています。調査では、外部で漏えいしたID・パスワードのリストを使ったなりすましが判明し、不正にログインされた可能性があるアカウントは249件としています。

閲覧された可能性があるのは氏名、住所、連絡先などの会員情報で、登録状況によって勤務先や家族、住所録の情報も含まれます。249件のうち1アカウントが持つ住所情報83件についても不正取得の可能性が示されました。アカウント数を、そのまま情報に含まれる人数の確定値として扱わないことが重要です。

同社は、9月29日に公表した郵便局アプリの事案で取得されたゆうIDとは重複せず、現時点で同社システムからの情報漏えいは確認していないと説明しています。今回の公表をデータベース全体の流出確定と読み替えたり、以前の事件の続報と一つにまとめたりしてはいけません。

出典:日本郵政:同件の公表資料PDF

2段階認証の適用日とサービス再開は別の情報

日本郵便の10月19日のお知らせは、20日からログイン時の2段階認証を必須にするとしています。また、他サービスと異なるパスワードへの変更と、パスキー設定の検討を案内しています。本稿で確認した案内だけから、すべての利用者が設定を完了した、停止していたサービスがすべて再開したとは判断できません。

利用者は、普段使う公式アプリや自分で確認した公式サイトから状況を確かめます。不審な連絡内のリンクを入口にせず、通知内容と公式案内を突き合わせてください。日本郵便は、電話やメール等でパスワードやクレジットカード番号を尋ねないと注意しています。問い合わせ先も正規サイトで確認するのが基本です。

出典:日本郵便:ゆうIDを安全にご利用いただくための大切なお知らせ

スポンサーリンク

外部のパスワード流出が自社の問題になる仕組み

一般にクレデンシャルスタッフィングは、別の場所で取得されたIDとパスワードの組み合わせを使い、ログインを試す攻撃です。サーバーの脆弱性を突いて認証処理を飛び越えなくても、正しい組み合わせが再利用されていれば、通常のログインとして処理される可能性があります。

Web運営者にとっては、パスワードの保存方式を安全にする施策だけでは、この入口を閉じられないことが課題になります。自社がパスワードを漏らしていなくても、他サービスでの使い回しが起点になるためです。ただし、今回使われたリストの具体的な流出元や、利用者ごとの管理状況は公表資料から確定できません。

利用者にはサービスごとの固有のパスワードを勧め、運営側はパスワードが知られても追加の確認が働く設計を検討します。OWASPも、再利用や盗難が起こり得ることを前提に認証を設計し、多要素認証と復旧経路を合わせて考える必要を説明しています。

出典:OWASP:Multifactor Authentication Cheat Sheet

Web版だけを強化しても経路が残る

自社サービスへ応用する際は、Webログイン、スマートフォンアプリ、旧画面、独自APIなど、同じ会員データへ到達できる入口を列挙します。画面に認証コードの入力欄を加えたことと、サーバー側で追加認証前の操作を拒否できることは別です。利用者が画面を経由しない要求を送っても、保護すべき情報へ届かない必要があります。

本サイトの提案として、認証状態を「パスワード確認済み」と「追加認証完了」に分け、後者が必要なAPIを明確にします。未完了の状態で会員詳細、住所録、メール変更などが読めたり更新できたりしないか、検証環境のテスト用アカウントで確認します。認証結果を画面の変数だけで管理しないようにしてください。

OWASPの資料も、複数の認証方法や別API、モバイルアプリがある場合の保護を指摘しています。これはゆうID内部の不備を断定する説明ではありません。今回の事案を受け、自社の実装レビューで確認する観点として扱ってください。

出典:OWASP:Multifactor Authentication Cheat Sheet

スポンサーリンク

会員情報の表示量が被害範囲を左右する

住所録や家族情報を持つ会員サイトでは、一人のアカウントに本人以外の情報が集まります。ログインを守る施策と並行して、ログイン直後にどの範囲を表示するかを見直す価値があります。一覧の全件表示、データ出力、配送先の詳細参照など、情報量が増える操作を特定します。

仮想例として、ECサイトの購入履歴から過去のすべての届け先が表示される画面を考えます。注文を再開するために必要な項目と、問い合わせ対応でだけ必要な項目を分け、詳細の再表示に追加確認を求める設計が考えられます。住所を隠しただけで安全とせず、応答JSONに全文が残っていないことも確認します。

過去データの保存期間も見直します。業務上必要な記録を場当たり的に削除するのではなく、利用目的、必要期間、参照権限を先に決めます。常に会員本人へ全履歴を即時表示する必要があるかを検討すれば、認証が破られたときに一度で見える情報を減らせます。

認証の復旧を抜け道にしない

2段階認証を導入すると、機種変更、端末紛失、登録先の利用停止などへの対応が必要になります。窓口の負担を減らすために、氏名や住所が分かるだけで追加認証を外せるようにすると、漏えいしたプロフィール情報が復旧手続きの突破に使われる懸念が生まれます。

OWASPは、アカウントを取り戻す仕組みがMFAを回避する経路にならないよう求めています。具体的な方式はサービスの性質によって異なるため、本サイトでは、追加認証の解除、連絡先変更、パスキー追加を重要操作として扱い、通常の問い合わせと承認手順を分けることを提案します。

復旧時は、確認した根拠、担当者、変更内容、通知結果を残します。秘密や身分証の複製を必要以上に保存しない設計も大切です。急いでいる利用者へ対応する場合も、担当者の裁量だけで確認を省けないよう、例外の承認と有効期限を運用に組み込みます。

出典:OWASP:Multifactor Authentication Cheat Sheet

試行回数だけでなく認証後の操作も見る

攻撃の監視をログイン失敗数だけに限定すると、正しい組み合わせで成功した後の操作を見落とします。自社の監視案として、追加認証の失敗、通常と異なる大量参照、住所録出力、連絡先変更、復旧の要求などを関連付けます。単一IPの遮断だけで対策が完了すると考えず、アカウントと操作の両方から確認します。

一方、失敗したアカウントを無条件に長時間停止すると、第三者が試行を繰り返すだけで利用者を締め出せることがあります。試行制限、追加確認、通知の組み合わせを検討し、正規利用者が復旧できる経路を用意します。閾値は自社の利用状況を見て決め、他社事件の件数をそのまま設定値にしません。

ログには、認証の段階と結果を記録し、入力されたパスワードや認証コードを保存しないようにします。調査用データの閲覧者と保存期間も限定します。監視を増やすことが、会員情報や認証情報を別の場所へ大量に集める結果にならないよう注意してください。

必須化を検証するための小さな試験

検証環境では、追加認証前のセッションで会員APIが拒否されること、認証コードの再利用ができないこと、期限切れのコードが通らないことを確認します。画面の表示とHTTPの結果を対応させ、正常な操作だけでなく途中で戻る、別タブを開く、再送する場合も試します。

次に、パスワード変更、登録先変更、追加認証の解除の後に、古いセッションがどうなるかを確かめます。すべての操作で同じ失効方針にする必要はありませんが、重要な設定を変更した直後も盗まれたセッションが利用できる設計になっていないか、明示的に判断します。

パスキーを追加するなら、登録時の本人確認と、実際の認証結果をサーバーが検証できるかを確認します。パスキーという名前だけで、端末管理や復旧の課題が消えるわけではありません。本番の他人のアカウントで試さず、許可されたテストデータと環境で検証してください。

スポンサーリンク

問い合わせ対応にも認証変更を反映する

必須化の前後は、ログインできないという連絡と、不正利用が疑われるという連絡を分けて受け付けると調査につながります。前者では端末や受信設定などの利用状況を、後者では身に覚えのない操作の時刻と通知を確認します。いずれもパスワードや認証コードを窓口へ送らせない方針を明示します。

案内ページには、正規の入口、必要な準備、アクセス集中時の対応、連絡先を整理します。利用者を急がせるだけのメールは、便乗した偽メールとの区別を難しくします。重要な変更ほど、メール以外にも公式サイト内で同じ案内を確認できるようにし、通知を見た利用者が安全に手続きを始められる状態を用意してください。

利用者保護と再開判断を同じ作業にしない

利用者への通知、認証の変更、影響範囲の調査、サービスの再開は、それぞれ完了条件が違います。自社の対応票では、どの対策が導入済みで、どの範囲が調査中なのかを分けて残します。「2段階認証を導入したので被害なし」といった説明は、過去の情報閲覧についての調査を代替しません。

今回の日本郵政の公表は、外部で流出した認証情報を利用したログインと、関連する会員情報の閲覧可能性を示すものです。利用者は公式案内に沿って自分の認証情報と通知を確認し、運営者は複数の入口、追加認証、表示データ、復旧経路を一つの認証設計として点検することが重要です。

出典・一次情報

本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
PHP8技術者認定ウィザード
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

あわせて確認したい対策・解説

スポンサーリンク

関連する記事

おすすめの書籍

キーワードから探す