靖國神社のオンライン授与品・頒布品サイトが外部から不正アクセスを受け、2026年11月11日に約1万4500件の個人情報の漏えいが公表されました。漏えいしたのは氏名・メールアドレスと、パスワードのハッシュ値およびその生成に用いる補助情報などで、神社は元のパスワードを特定されるおそれがあると説明しています。本記事の前半では、公式発表で確かめられる項目と時系列、会員がパスワードの使い回しと神社を装う連絡に備える手順を整理する構成です。後半は会員制の通販・申込みサイトを運営する側に向けて、ハッシュが漏れたときに何が起きるか、強制リセットと再ハッシュをどう実装するかをコード例で示します。
まとめ：靖国神社の不正アクセスで公表された事実と会員が今すぐ行う対応
サイトは10月28日に不正アクセスを把握した当日から止まっており、再開の時期は示されていません。原因はサイト管理会社とともに調査中です。
| 項目 | 公表内容（2026年11月11日掲載） |
|---|---|
| 対象サイト | オンライン授与品・頒布品サイト |
| 件数 | 約1万4500件（調査中で変わる可能性あり） |
| 漏えいした情報 | 氏名・メールアドレス |
| 漏えいした認証情報 | パスワードのハッシュ値と補助情報 |
| 漏えいしたアカウント情報 | 登録日時と利用状態 |
| 確認されていない情報 | カード番号・有効期限・セキュリティコード |
| ほかに漏えい未確認の情報 | 住所・電話番号・生年月日・購入履歴 |
| 把握と停止 | 10月28日に把握し同日に公開停止 |
| サイトのパスワード | 現在は変更できず、取扱いは改めて案内 |
会員がまず行うのは、このサイトと同じパスワードを使っている他のサービスのパスワード変更です。授与品サイト側のパスワードは今は変えられないため、まず使い回し先を守る対応を進めます。運営する側から見ると、ハッシュが漏れた時点で全会員のパスワードを「知られたかもしれない」ものとして扱い、次のログインで必ず再設定させる設計に切り替える場面です。
公式発表で確かめる授与品サイト不正アクセスの漏えい項目と時系列
約1万4500件の氏名・メールアドレス・パスワードハッシュという漏えい項目
靖國神社のお詫びとお知らせによると、漏えいしたのは会員の氏名とメールアドレス、パスワードに関する情報、会員アカウントの登録日時と利用状態です。パスワードは「ハッシュ値と、その生成に用いる補助情報」の形で保存されており、直接は読み取れないものの、第三者に元のパスワードを特定されるおそれがあると明記されています。
カード番号・有効期限・セキュリティコードは、今回の調査で漏えいが確認された情報に含まれていません。住所・電話番号・生年月日・購入履歴も、11月11日時点では漏えいが確認されていない扱いです。二次被害も現時点では確認されていません。件数は調査中の数字で、今後変わる可能性があると断られています。
10月20日のメルマガ委託先検知から11月11日公表までの2系統の時系列
同じ日に、靖國神社は別の不正アクセスも告知しています。メールマガジンの配信と社報「靖國」デジタル版の登録受付を委託していたブラストメール側の事案で、授与品サイトとは経路が異なります。
- 10月20日：配信委託先のブラストメールで外部からの不正アクセスを検知
- 10月21日：メールマガジンの配信とデジタル版の登録受付を停止
- 10月28日：授与品サイトへの外部からの不正アクセスを把握し、同日中に公開を停止
- 11月11日：2件のお知らせを公式サイトに掲載
配信委託先の件のお知らせでは、氏名とメールアドレスの漏えいは現時点で確認されていません。神社は同サービスの利用終了を決め、2027年1月開始予定だったデジタル版を延期しています。委託先側の事案の全体像はブラストメール不正アクセスと利用企業の報告・通知の手順で扱っています。本記事は11月12日に公式ページを確認した時点の内容で、その時点で続報は出ていませんでした。
会員がパスワード使い回しと神社を装う連絡による二次被害に備える確認手順
同じパスワードを使う通販・メール・SNSを決済の有無で並べた変更順
漏えいしたのはメールアドレスとパスワードの組み合わせの元になる情報です。割り出されたパスワードは、同じメールアドレスで登録した別のサービスへのログインに試されます。変更は被害の大きい順に進めます。
- このメールアドレス自体のパスワード（メールを取られると他のサービスの再設定も乗っ取られる）
- カードや口座を登録している通販・決済・ネット銀行
- SNSやメッセージアプリなど、本人になりすまして連絡を送れるサービス
- ポイントサイトや会員登録だけのサービス
変更時に設定するのは、サービスごとに異なるパスワードです。同じ文字列の末尾だけを変える付け方は、割り出された元の文字列から類推されます。二要素認証を設定できるサービスでは、この機会に有効にしておくと、パスワードが知られてもログインまでは通りにくくなります。
リンクの無い本人通知メールと神社を装う不審なメール・SMSの見分け方
漏えいの対象者には、漏えいしたメールアドレス宛てに個別の連絡が届きます。公式お知らせによると、件名は「【靖國神社】個人情報漏洩のお詫びとお知らせ（オンライン授与品・頒布品サイト）」で、メール内にリンクや添付ファイルはありません。送信元アドレスもお知らせに記載されているので、届いたメールと照合できます。
見分ける基準は単純です。リンクや添付ファイルがある時点で、この本人通知とは別物と判断できます。神社はメール・電話・SMSでパスワード、クレジットカード番号、銀行口座番号を尋ねることはないとしています。授与品サイトのパスワード変更を促すリンクが届いた場合も、サイトは公開停止中で変更できない状態なので、偽物です。
漏えい済みパスワードかをハッシュの先頭5文字で照合するPythonコード
変えた後のパスワードが既知の漏えいデータに含まれていないかは、Have I Been Pwned のAPIドキュメントにあるPwned PasswordsのrangeAPIで確かめられます。パスワードのSHA-1ハッシュの先頭5文字だけを送り、返ってきた候補の中に残りの35文字があるかを手元で照合する方式で、パスワードそのものは送信されません。APIキーは不要です。
# pwned_check.py（Python 3 標準ライブラリのみ）
import getpass, hashlib, urllib.request
def pwned_count(password: str) -> int:
sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
prefix, suffix = sha1[:5], sha1[5:]
req = urllib.request.Request(
f"https://api.pwnedpasswords.com/range/{prefix}",
# Add-Padding で応答件数をそろえ、応答サイズから先頭5文字を推測されにくくする
headers={"Add-Padding": "true", "User-Agent": "password-check-sample"},
)
with urllib.request.urlopen(req, timeout=10) as res:
for line in res.read().decode("utf-8").splitlines():
hash_suffix, count = line.split(":")
if hash_suffix == suffix:
return int(count)
return 0
if __name__ == "__main__":
n = pwned_count(getpass.getpass("確認するパスワード: "))
print(f"既知の漏えいデータに {n} 回出現" if n else "既知の漏えいデータには見つかりません")このコードは2026年11月12日に本記事の環境で実行し、試験用の文字列「password」で52,372,427回の出現が返ることを確かめています。見つからなかった場合も、そのパスワードが安全だと保証されるわけではありません。結果が1回以上なら、そのパスワードはどのサービスでも使わないでください。
ハッシュ値とソルトが漏れたときに元のパスワードが割り出される仕組み
ソルトはレインボーテーブルを防いでも辞書攻撃までは防げない理由
公表文は「補助情報」と書いており、方式は明かしていません。ハッシュと一緒に保存する補助情報の代表はソルトで、OWASPのPassword Storage Cheat Sheetはソルトを、パスワードごとに付ける一意のランダムな値と説明しています。ソルトがあると、同じパスワードでも会員ごとにハッシュが変わり、事前計算した対応表（レインボーテーブル）は使えなくなります。
一方で、ソルトは秘密の値ではありません。ハッシュとソルトを両方入手した攻撃者は、よく使われるパスワードの一覧を1件ずつ同じ計算にかけ、一致するものを探せます。「123456」や名前と誕生日の組み合わせのような短く推測しやすいパスワードは、この辞書攻撃で割り出される対象です。神社が「特定されるおそれ」と書いているのは、この性質を踏まえた表現と読めます。
OWASPのArgon2id・scrypt・bcrypt・PBKDF2の設定値と解読負荷
割り出しにかかる時間を決めるのは、ハッシュの計算が1回あたりどれだけ重いかです。OWASPは、パスワード保存に使う方式と最低限の設定値を次のように示しています。
| 方式 | OWASPの設定値 | 位置づけ |
|---|---|---|
| Argon2id | メモリ19MiB・反復2・並列1 | 第一候補 |
| scrypt | N=2^17（128MiB）・r=8・p=1 | Argon2idが使えない場合 |
| bcrypt | 作業係数10以上・入力72バイトまで | 既存システム向け |
| PBKDF2-HMAC-SHA256 | 反復600,000回 | FIPS-140準拠が必要な場合 |
これらは1回の計算にわざと時間とメモリを使わせ、総当たりの速度を落とす方式です。逆にMD5やSHA-256を1回かけただけの保存なら、同じ辞書を桁違いの速さで試せます。授与品サイトがどの方式だったかは公表されていないため、会員の側は「割り出される前提」で動くのが安全です。ハッシュ化そのものの考え方はハッシュ化と暗号化の違いとパスワード保管の仕組みで解説しています。
会員制サイトの運営側がハッシュ漏えい後に行う強制リセットの実装手順
NIST SP 800-63Bが求める漏えい時のパスワード変更強制とセッション失効
NIST SP 800-63B（改訂第4版）の3.1.1.2は、定期的なパスワード変更を求めてはならないとする一方で、認証情報が漏えいした証拠がある場合は変更を強制しなければならないと定めています。ハッシュとソルトが持ち出された状態は、この「証拠がある場合」に当たります。
実装では、保存中のハッシュでのログインを止めるだけでは足りません。ログイン済みのセッションやログイン状態を保つトークンが残っていると、攻撃者が先に入っていた場合にそのまま使い続けられます。ハッシュの無効化とセッションの失効は、同じ作業の中で実施する必要がある処理です。漏えいの事実は、本人への通知とあわせて個人情報保護委員会への報告の要否も判断します。不正の目的によるおそれがある漏えいは件数にかかわらず報告対象となる類型で、速報と確報の書き方は個人情報保護委員会への報告義務の実務にまとめています。
旧ハッシュを無効化し再設定トークンを使い捨てで発行するSQLとPython
次の例は、漏えい時点までに登録していた会員のハッシュを消し、再設定を必須にしてから、その会員のセッションを失効させるSQLです。テーブル名と列名は説明用の例なので、自社のスキーマに合わせて読み替えてください。
-- 漏えい時点（ここでは 2026-10-28）までに登録済みの会員を再設定必須にする
UPDATE users
SET password_hash = NULL,
must_reset = 1
WHERE created_at <= '2026-10-28 23:59:59';
-- 対象会員のログイン中セッションとログイン保持トークンを失効させる
DELETE FROM sessions
WHERE user_id IN (SELECT id FROM users WHERE must_reset = 1);
DELETE FROM remember_tokens
WHERE user_id IN (SELECT id FROM users WHERE must_reset = 1);再設定の案内で採るのは、漏えいの通知メールに再設定リンクを載せない形です。靖國神社の本人通知がリンクも添付も含めていないのと同じ考え方で、通知にリンクがあると、偽の通知メールとの区別がつかなくなります。会員がサイトを自分で開いて再設定を申し込んだときに、30分だけ有効な使い捨てのトークンを発行します。
# 再設定トークンの発行と消費（Python 3 標準ライブラリ＋DB-API）
import hashlib, secrets
from datetime import datetime, timedelta, timezone
def issue_reset_token(db, user_id: int) -> str:
token = secrets.token_urlsafe(32) # メールで本人にだけ送る値
token_hash = hashlib.sha256(token.encode("ascii")).hexdigest() # DBにはハッシュだけ保存
expires = datetime.now(timezone.utc) + timedelta(minutes=30)
db.execute(
"INSERT INTO password_reset_tokens (token_hash, user_id, expires_at) VALUES (?, ?, ?)",
(token_hash, user_id, expires.isoformat()),
)
db.commit()
return token
def consume_reset_token(db, token: str):
token_hash = hashlib.sha256(token.encode("ascii")).hexdigest()
row = db.execute(
"SELECT user_id, expires_at FROM password_reset_tokens"
" WHERE token_hash = ? AND used_at IS NULL",
(token_hash,),
).fetchone()
if row is None or datetime.fromisoformat(row[1]) < datetime.now(timezone.utc):
return None # 不正・使用済み・期限切れ
db.execute(
"UPDATE password_reset_tokens SET used_at = ? WHERE token_hash = ?",
(datetime.now(timezone.utc).isoformat(), token_hash),
)
db.commit()
return row[0]トークンもDBにはハッシュで保存します。トークン表が後から漏れても、そのまま再設定に使われないようにするためです。SQLとこのコードはSQLiteで実行し、漏えい時点より後に登録した会員が対象外になること、同じトークンが2回目には通らないことを確かめています。新しいパスワードの登録時には、前の章のrangeAPIで既知の漏えいデータに含まれるものを拒否すると、NIST SP 800-63Bが求める漏えいリストとの照合も満たせます。
ログイン時にArgon2idへ再ハッシュするPython実装と移行期間の扱い
漏えいを機に保存方式を見直す場合、全会員のパスワードを一度に変換することはできません。元のパスワードを持っていないからです。OWASPは、会員が次にログインしたときに入力されたパスワードを新しい方式でハッシュし直す方法を挙げています。argon2-cffiのAPIドキュメント（25.1.0）にあるcheck_needs_rehashを使うと、設定値が古いハッシュを判定できます。
# pip install argon2-cffi
from argon2 import PasswordHasher
from argon2.exceptions import InvalidHashError, VerifyMismatchError
# OWASP の Argon2id 最低構成（メモリ19MiB・反復2・並列1）
ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1)
def login(stored_hash: str, password: str):
"""照合に成功したら (True, 保存し直すハッシュ または None) を返す"""
try:
ph.verify(stored_hash, password)
except (VerifyMismatchError, InvalidHashError):
return False, None
if ph.check_needs_rehash(stored_hash):
return True, ph.hash(password) # 呼び出し側で users.password_hash を更新する
return True, None強制リセットを済ませた会員は再設定時に新方式で保存されるため、この再ハッシュが効くのは漏えい対象外の会員です。移行期間は新旧のハッシュが混在するので、方式名と設定値をハッシュ文字列に含める形式（Argon2の$argon2id$v=19$m=19456,t=2,p=1$のような表記）で保存しておくと判定がぶれません。このコードは本記事の環境に同ライブラリが無いため実行しておらず、公式APIドキュメントの記載に基づきます。bcryptからの移行の詳細はbcryptのコスト係数とArgon2idへの移行コードで扱っています。
授与品・物販の会員制サイトで認証情報を自社で持つかの判断基準
年に数回の購入ならゲスト購入を基本にしてパスワードを保管しない選択
授与品や記念品、イベントの申込みのように、1人が年に数回しか使わないサイトでは、会員登録とパスワードの保管を前提にしない設計を先に検討します。持っていないパスワードは漏れません。注文ごとにメールアドレスを確認するゲスト購入や、メールに届く使い捨てのコードでログインする方式なら、今回のような「他のサービスでの使い回しが危ない」という被害の広がり方は起きません。
この判断は、購入頻度が高く、配送先の再利用やポイントで会員の利便を出すサイトには当てはまりません。月に何度も買われる物販や、定期購入を扱うサイトで毎回のメール確認を求めると、離脱が増えます。その場合はパスワードを持ったうえで、前の章のArgon2idの設定、登録時の漏えいリスト照合、二要素認証の選択肢までを1セットで用意します。どちらにも決めきれない段階なら、会員登録を任意にしてゲスト購入を残すのが無難です。
サイト管理を委託している発注側が書面で確かめるハッシュ方式と監視
今回の授与品サイトは、サイト管理会社とともに原因を調べている段階です。運営を外部に委ねている発注側でも、漏えいした後に「どの方式で保存していたか」を答えられないと、会員への説明も報告もできません。委託先には次の4点を書面で確かめておきます。
- パスワードの保存方式と設定値（Argon2id・bcrypt等とそのパラメータ）
- 管理画面とサーバーへのログインに二要素認証がかかっているか
- 不審なログインや大量のデータ取得を検知したときの連絡経路と時間
- 漏えい時にハッシュの無効化とセッション失効を何時間で実行できるか
1点目に「MD5」「SHA-1」「平文」のような答えが返ってきたら、次の改修を待たずに見直しの対象です。APIの侵入口側の対策はAPI不正アクセス対策の実装手順にまとめています。保存方式や管理画面の守りが実際に破られにくいかは、設定を確かめるだけでは判断しにくい部分です。会員制サイトの認証まわりを外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
靖国神社のオンライン授与品・頒布品サイトへの不正アクセスについて、会員や会員制サイトの運営者から出やすい質問をまとめました。
靖国神社の不正アクセスで漏れた情報は何ですか？
オンライン授与品・頒布品サイトの会員の氏名、メールアドレス、パスワードのハッシュ値とその生成に用いる補助情報、会員アカウントの登録日時と利用状態です。件数は約1万4500件で、調査中のため変わる可能性があります。クレジットカード番号・有効期限・セキュリティコードと、住所・電話番号・生年月日・購入履歴は、11月11日時点で漏えいが確認されていません。
自分が対象かどうかはどうすれば分かりますか？
対象者には、漏えいしたメールアドレス宛てに神社から個別のメールが届きます。件名は「【靖國神社】個人情報漏洩のお詫びとお知らせ（オンライン授与品・頒布品サイト）」で、本文にリンクや添付ファイルはありません。届いたかどうか不安な場合は、公式お知らせに記載された総務課の窓口に問い合わせます。
授与品サイトのパスワードは変更したほうがよいですか？
サイトは10月28日から公開を停止しており、11月11日時点ではこのサイトのパスワードは変更できません。取扱いは改めて案内されます。今できるのは、同じパスワードを使っている他のサービスの変更です。メールアドレス自体のパスワードと、カードを登録した通販・決済サービスから先に変えます。
ハッシュ化されたパスワードでも解読されるのはなぜですか？
ハッシュは元に戻せない計算ですが、攻撃者はよく使われるパスワードを1件ずつ同じ計算にかけ、一致するものを探せます。ソルトは対応表による一括解読を防ぎますが、この辞書攻撃までは防げません。短く推測しやすいパスワードほど早く一致します。保存方式が軽い計算なら、試せる件数はさらに増えます。
メルマガの配信委託先の不正アクセスとは別の事案ですか？
別の事案です。メールマガジンと社報デジタル版の登録は配信サービスのブラストメールに委託しており、そちらでは10月20日に不正アクセスが検知されました。委託先の報告では、氏名とメールアドレスの漏えいは現時点で確認されていません。神社は同サービスの利用を終了し、デジタル版の開始を延期しています。
関連記事
- ブラストメール不正アクセス：421契約の配信先漏えいと、ピッコマ・エックスサーバーなど利用企業の公表、報告・通知の手順：靖國神社のメルマガ配信委託先で起きた事案
- 花キューピット情報漏洩：ログインとパスワード変更の手順、423万件の対象確認：パスワードの使い回しを点検する同種の事例
- Cognitoのパスワードリセット実装：ForgotPasswordと管理者リセット・ロックアウト設計：マネージドの認証基盤で強制リセットを組む方法
- ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説：ハッシュとソルトの基本
- bcryptとは：コスト係数・72バイト制限とArgon2idへの移行コード【2026年】：保存方式の移行の実装
