「パスワードは暗号化して保存しています」。多くのサービスがそう説明しますが、暗号化には種類があり、鍵の置き場所によっては守りになりません。今回の事案は、その違いが2,000万件を超える規模で表に出たものです。利用者として今すぐやることと、会員サイトや業務システムを運営する側が確かめることの両方を書きます。

何が起きたか

ソースネクストは10月15日、会員情報取得APIが不正に利用され、メールアドレス、パスワード、氏名、住所、電話番号、生年月日などを含む最大約2,252万件の会員情報が流出したと公表しました（不正アクセスは10月9日に始まり、13日に確認して同日に遮断、クレジットカード情報は含まれないとしています）。同社はITmediaの取材に対し、パスワードは暗号化して保存していたが、復号するための鍵にアクセスできるシステムが不正アクセスを受け、パスワードは復号された状態で流出したと説明し、開発時期の古いシステムで当時の暗号化方式を使い続けており、ハッシュ化への移行ができていなかったと述べています。全会員のパスワードを強制的に再設定する対応を取り、他のサービスで同じ組み合わせを使っている場合は変更するよう呼びかけています（ITmedia NEWS、INTERNET Watch、ASCII.jp）。

なぜ自社に関係があるのか

  • *利用者として。**2,252万件は、国内の多くの人が含まれる規模です。メールアドレスとパスワードに、氏名・住所・生年月日がそろっています。同じ組み合わせを他のサービスで使っていれば、リスト型攻撃で別のアカウントに入られます。氏名や住所を知ったうえで送られてくるフィッシングは、見分けが難しくなります。
  • *サービスを運営する側として。**本題はこちらです。暗号化とハッシュ化は別物です。暗号化は、鍵があれば元の文字列に戻せる仕組みで、戻す必要があるデータに使います。パスワードは、照合できればよく、元に戻す必要がありません。そのため、元に戻せない変換であるハッシュ化（ハッシュ関数の記事）で保存するのが基本です。

暗号化で保存すると、どこかに復号の鍵があり、鍵を使う仕組みがあります。今回の説明どおりなら、鍵そのものは流出していないのに、鍵を使えるシステムが侵入されたことでパスワードは平文に戻って流出しました。鍵と暗号文を同じ仕組みで扱っている限り、その仕組みが破られれば暗号化は意味を持ちません。

  • *古い方式が残る理由。**「開発時期が古く、当時の方式を使い続けていた」という説明は、多くの会社に当てはまります。暗号アジリティの記事で書いたとおり、方式は設計に埋め込まれると入れ替えが難しくなります。自社の会員サイトや業務システムが、パスワードをどの方式で保存しているかを即答できる担当者は多くありません。

明日やること

  • 利用者として。ソースネクストのアカウントを持っていれば、公式サイトから直接ログインしてパスワードを再設定する。同じメールアドレスとパスワードの組み合わせを使っている他のサービスも変更する。再設定を促す偽のメールが届く可能性があるため、メール内のリンクからは開かない
  • 運営する側として。自社の会員サイトや業務システムについて、パスワードが「暗号化」か「ハッシュ化」か、どの方式かを確認する。元に戻せる暗号化で保存しているなら、ハッシュ化への移行を計画に入れる。委託先が運用しているなら、同じ質問を文書で送る
  • APIと連携の点検。個人情報やパスワードをまとめて返すAPIがないか、あるなら認証・取得件数の制限・ログがそろっているかを確認する。今回は不正な取得が確認まで4日続いています。異常な量の取得を検知できるかも、確認の項目に入れる

もっと知るには

パスワードを元に戻せない形で保存する考え方はハッシュ関数とはで解説しています。流出したパスワードが他のサービスで使われる仕組みはパスワードの使い回しはなぜ「全滅」につながるのか、自社で漏えいが起きたときの報告の義務は個人情報の漏えい報告義務をご覧ください。

出典

ソースネクスト情報漏えいパスワードハッシュ化API