ソースネクスト 暗号化されていないパスワードが流出した理由とは
ソースネクストへの不正アクセスで会員情報が流出した問題では、「暗号化がない状態のパスワード」が含まれていたことをNHKなどが報じており、注目を集めています。
どのような方式でパスワードを管理していたのか、運営会社に聞いてみました。
システム連携用に暗号化して保存していた
ソースネクストの発表によれば、直接的な原因は会員情報取得APIを不正に利用されたことによるもので、対象件数は2251万9960件としています。
まず、具体的な件数を特定できた理由について聞いてみたところ、「APIのログのデータから対象件数を特定した」(ソースネクスト広報)とのことでした。
こうしたAPIでは、本来であればログインした会員本人の情報だけを取得できるはずが、何らかの理由で他人の情報まで取得できてしまう状態になっていたとみられます。
今回の事例で気になる点としては、流出した情報の中に「パスワード」が含まれていたことが挙げられます。
ソースネクストによると、パスワードは「暗号化」して保存していたとのことですが、暗号鍵にアクセスできるシステムが不正アクセスを受けたことで、「元の文字列を判読できる状態で漏洩した」(広報)と説明しています。
これに対して、なぜパスワードをハッシュ化した状態(ハッシュ値)で保存していなかったのか、という指摘が多くあるようです。
パスワードの「暗号化」と「ハッシュ化」の違い
・暗号化: パスワードを暗号鍵を使って別の文字列に変換する方式。対応する鍵があれば元のパスワードに復号できる
・ハッシュ化: パスワードを一定の規則で別の文字列に変換する方式。ハッシュ値から元のパスワードを復号することは基本的にはできない
ハッシュ値なら安全というわけではなく、ハッシュ化の方式によっては元の文字列を特定できる可能性は残るものの、データベース内に元のパスワードを保存しておく必要はなくなります。
また、会員情報を取得するAPIにおいて、戻り値にパスワードを含めるのは特徴的な仕様といえます。一般的にはパスワードを含めない設計が多いのではないでしょうか。
この点について確認したところ、「ライセンス管理システムとの連携など、パスワードが必要な作業で使う必要があるAPIであったため、パスワードも含めていた」(ソースネクスト広報)とのことでした。
最近の事例として、KDDIがISP向けに提供するメールシステムが多数の平文パスワードを保存していたことが明らかになったように、さまざまな事情や経緯からハッシュ値ではなく元のパスワード文字列を保存しているケースは残っているとみられています。
ソースネクストの事情は分かりませんが、自社のデータベースにパスワードを暗号化して保存していたことから、少なくとも「平文のまま保存するのはまずい」という意識があったことはうかがえます。
しかし今回の事例では不正アクセスにより、「元の文字列を判読できる」状態で漏洩したとのことから、実質的にパスワードを平文で保存していたのと変わらない事態になったといえそうです。
ソースネクストは会員向けにパスワードを再設定するよう案内しているものの、新しいパスワードについても同様に暗号化してサーバーに保存されるとのことです。
すでにAPIへの不正アクセスは対策済みで、再発しないことを確認しているとのことですが、今後はパスワードを持たない方式への移行も検討してほしいところです。
パスワードの使い回しをやめよう
ソースネクストではすべての利用者のパスワードをリセットしたとのことから、急いで変更する必要はなさそうです。
すべての利用者のパスワードは変更済みと案内している(Webサイトより)注意すべきは、ソースネクスト以外のサービスで同じパスワードを使い回している場合です。元のパスワード文字列が漏洩したことで、不正にログインされる恐れがあります。
利用者側でできる対策としては、サービスごとに異なる十分に長いパスワードを使うことが推奨されています。筆者はパスワード管理ツールを使って、数百種類のサービスそれぞれに数十文字程度の十分に長いパスワードを設定しています。
ソースネクストが取り扱っている「1Password」のような有料アプリ以外にも、OSやブラウザに無料で搭載されている機能もあります。自分や家族のパスワード管理を見直す機会にしてはどうでしょうか。
(やまぐち けんた)1979年生まれ。10年間のプログラマー経験を経て、2012年にフリーランスのITジャーナリストとして独立。日経クロステック(xTECH)やASCII.jp、ITmedia、マイナビニュースなどの媒体に寄稿し、2021年からは「Yahoo!ニュース エキスパート」として活動しています。