セキュリティ

SONICWIRE不正アクセスの確定値と対応：全会員パスワード無効化と再設定の実装

SONICWIRE不正アクセスの確定値と対応：全会員パスワード無効化と再設定の実装

クリプトン・フューチャー・メディアは2026年10月19日、音源・音楽制作ソフトの販売サイト「SONICWIRE」と、販売店向けの「D2R」に第三者の不正アクセスがあったと公表しました。10月22日の更新では、SONICWIRE会員の登録情報362,137件が参照・取得されたと確定値を示した形です。本記事では、公式発表の2つの版から対象になる人と情報、会員がいま行う対応、11月1日までとされる再開目標を整理します。後半では、同社が実施した「全会員のパスワードの無効化と初回ログイン時の再設定」を、自社サービスで行う場合の実装をSQLとDjangoのコードで示します。

まとめ：SONICWIRE不正アクセスで確定した情報の範囲と会員が行う3つの対応

確定しているのは、SONICWIRE会員362,137件の氏名・メールアドレス・ソルト付きでハッシュ化されたパスワード、2021年11月19日までに領収書・請求書・見積書を発行した際の入力情報671件、会員以外のニュースレター購読者11件のメールアドレスが取得されたことです。クレジットカード情報は同社のシステムで保持しておらず、漏えいの可能性はないとされています。侵入経路は公表されていません。

会員が行うのは次の3つです。

  1. SONICWIREと同じメールアドレスとパスワードの組み合わせを使っている他のサービスで、パスワードを変える
  2. クリプトンや関係先を名乗るメール・SMSのURLや添付ファイルを開かず、パスワードを入力しない
  3. サービスの再開後、初回ログインの画面で新しいパスワードを設定する（旧パスワードは使えない）

SONICWIREのパスワードは全会員分が無効化済みです。サイトが止まっているいま、SONICWIRE自体の操作は要りません。先に手を付けるのは、使い回している他のサービスです。

自分は対象か｜SONICWIRE会員362,137件と請求書入力671件の区分

10月22日の更新で示された3つの区分と漏えいした項目の違い

10月22日に更新されたクリプトンの公式発表は、取得された情報を3つに分けています。区分によって漏れた項目が違うため、自分がどこに当たるかで注意すべき連絡の種類も変わります。

区分 件数 取得された項目
SONICWIRE会員 362,137件 氏名、メール、ハッシュ化パスワード、登録日等
2021年11月19日までの帳票入力 671件 会社名・所属名、氏名、住所、電話番号
会員以外のニュースレター購読者 11件 メールアドレス、購読日時等

住所と電話番号が含まれるのは、2021年11月19日までに領収書・請求書・見積書を発行した671件だけです。この区分は任意入力の項目を含むため、対象の項目は人ごとに違う。法人名義で見積書を取った楽器店や制作会社は、会社宛ての請求書を装った郵便や電話にも注意が要ります。ニュースレターだけを購読していた11件には、11月6日（金）までに連絡するとされています。

D2Rの登録店舗については、10月19日の初報で氏名・店舗名・ログインID・ハッシュ化されたパスワードが対象になり得るとされ、対象の店舗には個別に連絡済みと書かれています。22日の更新には店舗の件数がありません。

カード情報とシリアル番号とECストアが対象外とされた公式の根拠

公式発表は、クレジットカード情報を当社のシステムで一切保持していないこと、決済プログラムの改ざんもないことを確かめたとし、カード情報の漏えいの可能性を否定しています。ライセンス登録済みのシリアル番号も第三者に取得されていないこと、SONICWIRE関連ECストア（ec.crypton.co.jp）から情報が漏れていないことも確認済みです。

カードの再発行や、購入済みのソフトの再登録は、この発表を根拠にする限り不要です。カード会社やソフトのライセンスを理由に連絡してくる相手がいたら、それ自体を疑ってください。

10月17日の検知から11月1日の再開目標まで｜公式発表の時系列と更新点

検知から約3時間半でサーバーを止めた初動と警察・個情委への報告

初報と更新の2つの版を日付順に並べると、検知から約3時間半でサーバーの停止まで進んでいます。

日時 出来事
10月17日（土）20時頃 不正アクセスの可能性を確認
同日 侵害アカウントの無効化、社内ドメインのIP制限
同日23時39分頃 該当サービスのサーバー停止を完了
10月18日（日） 警察へ第一報
10月19日（月） 個人情報保護委員会へ報告、初報を公表
10月22日 確定値と再開目標を追記

初報は、検知後に「侵害アカウントの無効化や社内ドメインのIP制限」を行ったと書いています。ここで言う侵害アカウントが会員のものか、運営側のものかは明らかにされていません。原因の究明は、外部の専門機関への調査依頼を含めて続いています。

最大約42万件から362,137件へ変わった初報と10月22日更新の差分

初報の「最大約42万件」は、ニュースレター購読者を含むSONICWIRE会員の上限として示された数字です。22日の更新は、会員362,137件、帳票入力671件、購読者11件に分けて件数を確定させました。差の約6万件が漏れなかったと読むより、初報は調査途中の上限だったと捉えるのが正確です。

再開の見込みも変わりました。初報は「未定」でしたが、更新ではSONICWIREとD2Rを新たなサーバー上で再構築しており、2026年11月1日（日）までの再開を目指すとしています。ECストアの復旧の目途は未定のままです。詳しい日程は決まり次第、同じお知らせのページを更新して伝えるとされています。

会員が今日やること｜再開後の初回ログインと使い回しパスワードの変更順

ソルト付きハッシュでも他サイトで使い回しのパスワードを先に変える理由

漏れたパスワードは平文ではなく、ソルト付きのハッシュ値です。それでも同社は「万が一パスワードが復元された場合」に、同じメールアドレスとパスワードの組み合わせで他のサービスへのログインが試される恐れがあるとして、変更を求めています。

ハッシュから元のパスワードを割り出す難しさは、ハッシュの方式とパスワードの強さで決まります。辞書に載る単語や短いパスワードは、ソルトがあっても総当たりで当たりやすい。SONICWIREがどの方式を使っていたかは公表されていないため、利用者の側では「復元されうる」と考えて動くのが妥当です。変える順番は、メール、決済のあるサービス、音楽配信や制作関連のアカウントの順にします。メールを乗っ取られると、他のサービスのパスワード再設定を相手に許すからです。ハッシュの仕組みはハッシュとはで解説しています。

SONICWIREを装うメールを見分ける基準と公式の問い合わせ窓口

今回漏れたのは氏名とメールアドレスの組です。宛名に本名が入ったメールが届いても、本物の証拠にはなりません。同社は、不審なメールやSMSのURL・添付ファイルを開かないこと、個人情報やパスワードを入力・回答しないことを求めています。

本件の公式の窓口は、クリプトンのユーザー向けお問い合わせです。メールのリンクから開かず、クリプトンの公式サイトを自分で開いて、ニュースリリースから辿ってください。再開時の初回ログインも、ブックマークか検索で開いたSONICWIREのページから行います。「パスワードの再設定はこちら」とリンクの付いたメールは、本物であってもクリックしない運用が安全です。手口の型はフィッシング詐欺とはにまとめています。

全会員パスワードを一括で無効化する実装｜ハッシュ置換とセッション失効

漏えいした旧ハッシュを照合に使わせない無効化フラグと列の置き換え

ここからは、会員制サービスを運営する側が同じ措置を取る場合の実装です。NIST SP 800-63B-4は、定期的なパスワード変更の強制を禁じる一方で、認証情報が侵害された証拠があるときは変更を強制しなければならない（SHALL）と定めています。漏えいは、この「証拠」に当たります。

無効化で守るのは2点です。漏れた旧ハッシュと一致するパスワードではもうログインできないこと、そして会員ごとに「再設定が必要」と分かることです。PostgreSQLでの例を示します。

-- PostgreSQL 13 以降（gen_random_uuid を使う）
BEGIN;

-- 1. 再設定が必要な会員と、無効化した時刻を記録する列
ALTER TABLE users ADD COLUMN IF NOT EXISTS password_reset_required boolean NOT NULL DEFAULT false;
ALTER TABLE users ADD COLUMN IF NOT EXISTS credentials_revoked_at timestamptz;

-- 2. 全会員の旧ハッシュを、どのパスワードとも一致しない値に置き換える
UPDATE users
SET password_hash = '!' || gen_random_uuid()::text,
    password_reset_required = true,
    credentials_revoked_at = now();

-- 3. ログイン中のセッションと、発行済みのAPIトークンを失効させる
DELETE FROM user_sessions;
UPDATE api_tokens SET revoked_at = now() WHERE revoked_at IS NULL;

COMMIT;

2の先頭の ! は、ハッシュ方式の接頭辞（$2b$ や argon2id など）と重ならない値にするためです。照合処理がこの値を解釈できずに例外を投げないか、本番と同じ版のライブラリで事前に確かめてください。旧ハッシュを別テーブルに退避する設計は取りません。すでに外部に出た値を社内に残しても、調査の役に立つ場面はほとんどなく、二度目の漏えいの材料になるだけです。

Djangoの全会員パスワード無効化コマンドとセッション失効の仕組み

Djangoなら、公式リファレンスにある set_unusable_password() が同じ役割を持ちます。この印の付いた会員は check_password() が二度と True を返さない、と明記されています。

# accounts/management/commands/revoke_all_passwords.py
from django.contrib.auth import get_user_model
from django.core.management.base import BaseCommand


class Command(BaseCommand):
    help = "全会員のパスワードを使えなくし、再設定を必須にする"

    def handle(self, *args, **options):
        User = get_user_model()
        batch, total = [], 0
        for user in User.objects.filter(is_active=True).iterator(chunk_size=2000):
            user.set_unusable_password()          # 会員ごとに乱数入りの値になる
            user.password_reset_required = True   # カスタムユーザーモデルに追加した列
            batch.append(user)
            if len(batch) == 2000:
                User.objects.bulk_update(batch, ["password", "password_reset_required"])
                total += len(batch)
                batch = []
        if batch:
            User.objects.bulk_update(batch, ["password", "password_reset_required"])
            total += len(batch)
        self.stdout.write(f"{total} users revoked")

python manage.py revoke_all_passwords で実行します。セッションを個別に消す処理を書いていないのは、Djangoの認証システムの解説にあるとおり、ログイン中のセッションにはpassword列から作ったHMACが入っており、password列が変わると次のリクエストで照合が外れてログアウトされるためです。この仕組みはセッションの保存先がDB・キャッシュ・署名付きCookieのどれでも働きます。ただし、Djangoのセッションとは別に発行したAPIトークンやリフレッシュトークンには効きません。それらは上のSQLの3と同じく、明示的に失効させてください。セッションの失効の設計はセッション管理とは、トークンの失効はAPI不正アクセス対策の実装手順で扱っています。

初回ログインで再設定させるフロー｜メール確認トークンと漏えい照合

旧パスワードで本人確認しない再設定フローとトークンの単回・期限

初回ログインの画面で「現在のパスワード」を入力させてはいけません。旧パスワードは攻撃者の手にある前提だからです。本人確認は、登録メールアドレスに送る再設定用のトークンで行います。OWASPのForgot Password Cheat Sheetは、トークンを暗号論的に安全な乱数で作ること、1回しか使えず一定時間で失効すること、URLをHostヘッダーから組み立てないことを求めています。再設定のあとに自動でログインさせず、通常のログイン画面を通すことも同じ資料の推奨です。

Djangoでは、ここに見落としやすい落とし穴があります。標準の PasswordResetForm は、stable/5.2.xのソースの get_users() で、使えないパスワードの会員を再設定メールの送り先から外しています。前の章のコマンドで全員を無効化すると、そのままでは誰にも再設定メールが届きません。

# accounts/forms.py
from django.contrib.auth import get_user_model
from django.contrib.auth.forms import PasswordResetForm


class BreachPasswordResetForm(PasswordResetForm):
    """一括無効化した会員にも再設定メールを送る"""

    def get_users(self, email):
        User = get_user_model()
        field = User.get_email_field_name()
        users = User._default_manager.filter(**{f"{field}__iexact": email, "is_active": True})
        return (u for u in users if u.has_usable_password() or u.password_reset_required)

このフォームを PasswordResetView.as_view(form_class=BreachPasswordResetForm) に渡します。Djangoの標準トークンはpassword列と最終ログイン日時を材料にしているため、再設定が済むと同じトークンは使えなくなり、既定の有効期限（PASSWORD_RESET_TIMEOUT）は3日です。36万件規模で一斉に再設定が来ると、3日のうちに使われないトークンも多く出ます。期限切れの画面から再送できる導線を、先に用意しておいてください。

Pwned Passwordsのk-匿名性APIで漏えい済みパスワードを拒否する

新しいパスワードの登録時には、過去の漏えいに含まれるパスワードを拒否します。NIST SP 800-63B-4は、パスワードの設定・変更のたびに、よく使われる値や侵害された値のブロックリストと照合しなければならない（SHALL）としています。Have I Been PwnedのPwned Passwords APIは、SHA-1ハッシュの先頭5文字だけを送り、該当する残りの部分を受け取って手元で照合する方式です。パスワードそのものも完全なハッシュも外へ出ません。

# 標準ライブラリのみ・APIキー不要
import hashlib
import urllib.request


def pwned_count(password: str) -> int:
    """漏えいデータに含まれた回数を返す（0なら未検出）"""
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]
    req = urllib.request.Request(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        headers={"Add-Padding": "true", "User-Agent": "password-reset-check"},
    )
    with urllib.request.urlopen(req, timeout=5) 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__":
    print(pwned_count("password123"))  # 漏えい済みの値なので大きな数が返る

Add-Padding: true は、応答の件数を毎回800〜1,000件にそろえ、通信量からどの先頭5文字を問い合わせたか推測されにくくするヘッダーです。水増しの行は回数が0なので、上の照合では一致しません。APIに届かないときに登録を止めるか通すかは、事前に決めておいてください。漏えい直後の一斉再設定ではアクセスが集中するため、タイムアウト時は照合を飛ばして登録を通し、ログに残す設計を勧めます。照合と同時に入れるレート制限はパスワードリスト攻撃とはで解説しています。

一括無効化を選ぶ条件と見送る場面｜漏えい範囲・ハッシュ方式・連絡手段

ハッシュ方式と漏えいの範囲から全件無効化か対象限定かを決める基準

パスワードのハッシュを含む会員テーブルが丸ごと取得された、または取得された範囲を絞れない。この場合は、ハッシュ方式が何であれ全件を無効化します。OWASPのPassword Storage Cheat Sheetが推す Argon2id（メモリ19MiB以上・反復2・並列1）で保存していても、弱いパスワードは時間をかければ当たるからです。MD5やSHA-1をそのまま使っていた、あるいはソルトが無かったなら、迷う余地はありません。

見送ってよいのは、取得されたのがパスワードの列を含まないテーブルだと、ログで言い切れる場面です。氏名とメールアドレスだけが漏れたのなら、全員を締め出すと正規の利用者の離脱と問い合わせの増加だけが残ります。その場合はパスワードを止めず、フィッシングの注意喚起と、次回ログイン時の漏えい照合に留めます。逆に「パスワード列は見られていないはず」という推測だけで見送るのは失敗パターンです。判断の根拠はデータベースの監査ログやクエリログであって、担当者の記憶ではありません。

通知メールにログインリンクを入れない設計と個情委への報告期限

全会員への通知メールには、ログインや再設定のリンクを入れません。漏れたメールアドレス宛てに、本物そっくりの偽メールが届く時期と重なるからです。本物の通知に「サイトを自分で開いて、ログイン画面から再設定する」とだけ書いておけば、リンク付きのメールはすべて偽物だと会員に伝えられます。クリプトンの発表も、利用者へのお願いはURLを開かないことと、初回ログイン時の再設定です。

不正アクセスによる漏えいは、件数にかかわらず個人情報保護委員会への報告の対象です。個人情報保護委員会の案内は、発覚したらまず速やかに報告し、不正な目的で行われたおそれがある場合は発覚日から60日以内に確報を出すとしています。速報と確報の書き分けは個人情報保護委員会への報告義務で整理しました。

無効化のコマンドは、事故が起きてから書くと、本章で挙げたフォームの除外やトークンの失効漏れで止まります。自社の会員サイトやECで、全会員のパスワードとセッションを一度に止められる作りになっているかを確かめたい場合は、認証基盤・ID管理システム開発で、再設定フローと漏えい照合を含めた改修を相談できます。

よくある質問

SONICWIREとD2Rへの不正アクセスについて、会員と運営側の開発者から出やすい質問をまとめました。2026年10月22日の公式発表時点の情報です。

SONICWIREはいつ再開しますか？

2026年10月22日の更新で、クリプトンはSONICWIREとD2Rについて、新たなサーバー上で環境を再構築しており、2026年11月1日（日）までの再開を目指すとしています。詳しい日程は決まり次第、同じお知らせのページを更新して伝えるとのことです。SONICWIRE関連ECストア（ec.crypton.co.jp）の復旧の目途は未定です。再開の情報は、メールのリンクではなくクリプトンの公式サイトのニュースリリースで確かめてください。

自分の情報が漏れたかどうかはどう確かめればよいですか？

SONICWIREに会員登録していれば、362,137件に含まれると考えて動くのが安全です。クリプトンは対象者の登録メールアドレス宛てに順次連絡するとしていますが、メールの到着を待つ必要はありません。2021年11月19日までに領収書・請求書・見積書を発行した人は、住所と電話番号も対象になり得ます。迷ったときは、公式サイトから開いたユーザー向けお問い合わせの窓口に尋ねてください。

SONICWIREのパスワードは今すぐ変えるべきですか？

今は変える操作ができません。クリプトンは全会員のパスワードを無効化しており、サービスの再開後、初回ログインの際に再設定する流れです。今すぐ行うべきなのは、SONICWIREと同じメールアドレスとパスワードの組み合わせを使っている他のサービスの変更です。再設定のときは、他のサービスで使ったことのない新しいパスワードを選んでください。

購入済みの音源やソフトは使えなくなりますか？

公式発表は、ライセンス登録済みのシリアル番号が第三者に取得されていないことを確認したとしています。シリアル番号の漏えいを理由とした再登録は、この発表を前提にする限り不要です。ただし、サービスの停止中はSONICWIREのサイトにログインできず、D2Rも止まっているため、停止中に新たな製品登録や購入の手続きが必要な場合は再開を待つことになります。

全会員のパスワードを無効化すると既存のログイン状態はどうなりますか？

パスワードの値を変えるだけでは、発行済みのセッションやAPIトークンが残る実装があります。Djangoの標準のセッションは、password列から作るHMACで照合するため、列が変われば次のリクエストでログアウトされます。一方、自前で発行したAPIトークンやリフレッシュトークンは別に失効させなければ使えたままです。無効化の処理は、パスワード、セッション、トークンの3つを1つの作業として実行してください。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21　テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.21　テックブログ NEC委託先の不正アクセスとは｜顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  3. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期
  4. 2026.10.22　テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  5. 2024.07.05　コラム XAMPPの脆弱性とは？危険性とCVE-2024-4577への対策をわかりやすく解説【2026年10月】

RELATED POSTS 関連記事

一覧へ戻る

目次