LASSIC Media らしくメディア

会員向けサービスや業務システムにログイン機能を組み込む場面では、利用者のパスワードをどう保存するかが設計上の論点になります。保存方法を誤ると、万一の情報漏えい時に被害がそのままログイン情報の流出へ直結する恐れがあるのです。開発を発注する立場からすると、画面の使い勝手や機能要件に比べて見えにくい部分だからこそ、あらかじめ論点を押さえておく価値があります。

本記事は、ハッシュ関数そのものの一般的な仕組みではなく、認証における「パスワードの保存」に絞って解説する記事です。ハッシュ関数の基礎や用途については、別記事「ハッシュ関数とは」に譲ります。ここでは平文保存の危うさ、ソルト、ストレッチング（反復処理）、パスワード専用ハッシュ関数を扱う構成です。発注担当者やプロジェクトマネージャーが押さえておきたい、保存設計の勘所を整理します。

パスワードハッシュとは

パスワードハッシュとは、利用者のパスワードを元に戻せない形へ変換して保存し、万一データが漏れても元のパスワードを読み取られにくくする仕組みです。

この考え方の背景には、パスワードをそのまま（平文で）保存する設計の危うさがあります。データベースが漏えいすると、保存された文字列がそのまま利用者のパスワードになり、攻撃者はログインを試みるだけで不正アクセスが成立してしまうでしょう。他のサービスで同じパスワードを使い回している利用者がいれば、被害は元のサービスの外側まで広がります。

平文保存が発覚した場合、影響範囲の調査や利用者への周知、パスワード再設定の案内など、対応には相応の時間と工数がかかるでしょう。保存方式そのものを見直す以前に、まず何が漏れたのかを正確に洗い出す作業が発生し、通常の開発・運用業務とは別の対応工数を割くことになります。保存の設計段階でこうした事態を避けておくほうが、後から対応するよりも負担は小さく済むはずです。

暗号化して保存する方式にも注意が必要です。暗号化は復号（元に戻すこと）を前提とした仕組みのため、復号鍵が漏えいすれば平文と同じ状態に戻ってしまいます。鍵の保管場所や権限管理まで含めて設計しなければ、暗号化しているという見た目だけが先行し、実際の対策が伴わない事態になりかねません。

発注担当者やプロジェクトマネージャーにとって、この論点は開発会社まかせにしにくい部分でもあります。パスワードの保存方式は、画面や機能の見た目には現れず、要件定義や設計レビューの段階で確認しないまま進んでしまいやすい項目だからです。会員データや取引先の担当者アカウントを扱うシステムでは、保存設計の妥当性を発注側としても押さえておく意義があるといえるでしょう。

ハッシュ関数は、この逆をいく性質を持つ変換です。入力から出力を計算するのは容易でも、出力から元の入力を逆算することは計算量的にむずかしいという、一方向の性質を備えています。パスワードをハッシュ化して保存すれば、データベースが漏れても、そこから元のパスワードを割り出す作業には相応の計算負荷がかかるわけです。ただし、一方向ハッシュにそのまま通すだけでは十分と言えない理由が別にあり、次の章で確認していきましょう。

保存方式の話とは別に、パスワードの使い回し自体もリスクの一因です。IPA（情報処理推進機構）は、複数のサービスで同じパスワードを使い回さないよう利用者に呼びかけています。あるサービスから平文に近い形でパスワードが漏れると、そのパスワードと利用者IDの組み合わせまで漏れてしまうのです。この組み合わせを使って他サービスへ次々とログインを試みる手口は、パスワードリスト攻撃と呼ばれています。サービス提供側の保存方式と、利用者側のパスワード運用は、どちらか一方だけで完結する対策ではありません。

一方向ハッシュだけでは足りない理由

一方向のハッシュ関数にパスワードを通すだけでは、保存の設計としてまだ不十分です。理由は、同じパスワードを入力すれば、常に同じハッシュ値が出力される点にあります。

この性質を突かれると、攻撃者は「よく使われるパスワード」や辞書に載っている単語をあらかじめハッシュ化し、対応表を作っておくことができます。この対応表はレインボーテーブルと呼ばれ、漏えいしたハッシュ値と照合するだけで、元のパスワードを短時間で特定できてしまう手口です。同じ入力からは同じ出力しか得られない一方向ハッシュの弱点を、逆手に取った攻撃といえます。

総当たり（ブルートフォース）攻撃も見過ごせません。短い文字列や単純な組み合わせのパスワードであれば、GPUなどの計算資源を用いて片っ端から試行できてしまいます。OWASPは、Webアプリケーションセキュリティに関する国際的なコミュニティです。公開しているガイド「Password Storage Cheat Sheet」では、平文保存やSHA-256など高速な汎用ハッシュを取り上げています。そのまま使うべきではないという指摘です。計算が速いことは、攻撃者にとって総当たりの試行を速くできることも意味します。

ここで一つ整理しておきたいのが、「パスワードの複雑さを求める運用ルール」と「保存方式の設計」は別の対策だという点です。桁数や文字種を増やす運用は、利用者が入力する段階での推測されにくさを高めるものであり、保存されたデータが漏えいした後の読み取られにくさとは、守る対象が違います。両方をあわせて設計して初めて、入口から保存までの経路をひととおり押さえたことになるでしょう。

つまり、一方向であることだけでは、レインボーテーブルや総当たりへの備えとしては足りません。ここで効いてくるのが、次に説明するソルトという工夫です。

ソルトが担う役割

ソルトとは、利用者ごとに異なるランダムな文字列を、ハッシュ化する前のデータに付け加える仕組みです。IPA（情報処理推進機構）は、サービス提供者に対しパスワードをソルト付きハッシュ値として管理するよう求めています。ソルトについては「利用者ごとに異なる値で生成した文字列」と説明しています。

ソルトを加えると、同じパスワードを使う利用者が複数いても、それぞれのハッシュ値は異なる結果になるのです。攻撃者があらかじめ用意したレインボーテーブルは、特定のソルトの組み合わせに対応していないため、そのままでは使い回せません。ソルトが一人ひとり違う値であるほど、事前計算による攻撃の効率は落ちていきます。

上の図は、平文のまま保存する場合と、ソルト＋反復ハッシュで保存する場合の違いを表したものです。同じ情報漏えいが起きても、読み取られやすさには大きな差が生まれます。

下表に、保存方式ごとに防げる攻撃の違いをまとめます。方式を重ねるほど、対応できる攻撃の幅が広がる点が見て取れるでしょう。表の上から下に進むほど対策が積み上がっており、実際の運用では表の下段（ソルト＋ストレッチング）を満たす方式を選ぶことが出発点になります。

ソルトそのものは秘密にする必要がなく、ハッシュ値と並べて保存してかまいません。ソルトの役割は同じパスワードを別の値に変換することであり、値自体を隠すことではないためです。bcryptやArgon2などのパスワード専用ハッシュ関数では、ソルトの生成と管理を内部で自動的におこなうため、開発者が個別に実装する場面は少なくなっています。

ソルトを利用者ごとに生成する際は、予測しにくい乱数を用い、使い回さないことが前提です。ソルトの値が短かったり、複数の利用者で同じ値を使い回していたりすると、レインボーテーブルの対応表を作り直せる余地が生まれます。その分だけ、ソルトを加えた意味合いが薄れてしまうでしょう。

OWASPの「Password Storage Cheat Sheet」では、ソルトに加えて「ペッパー」という層を組み合わせる手法も紹介されています。ペッパーとは、データベースとは別の場所に保管しておく共有の秘密値のことです。データベースそのものが漏えいしても、ペッパーは別の保管場所にあるため、攻撃者が両方を同時に入手しない限り、パスワードの解読はさらにむずかしくなります。ただしペッパーの管理には鍵管理の仕組みが別途必要になるため、まずはソルト付きのパスワード専用ハッシュ関数を適切に使うことが優先事項になるでしょう。

ストレッチングとパスワード専用ハッシュ関数

ソルトだけでは、総当たり攻撃そのものの速さは変わりません。そこで組み合わされるのが、ストレッチング（反復処理）という工夫です。ハッシュ化の計算を何度も繰り返すことで、1回あたりの計算時間をわざと長くし、総当たりで試せる回数を減らします。

ストレッチングは、鍵導出関数（KDF、パスワードなどの元データから鍵やハッシュ値を導く関数）の特徴のひとつです。Wikipedia日本語版「鍵導出関数」は、パスワードベースの鍵導出関数の特徴を次のように説明します。「多数の反復計算をするなど、わざと計算に時間がかかるように設計される」というものです。この設計によって、総当たり攻撃がむずかしくなります。

この考え方を実装したのが、パスワード保存専用のハッシュ関数です。単純に反復回数を増やすだけでなく、計算の途中で大量のメモリを使うよう設計された方式も広がっています。メモリを多く使う処理は、専用のハードウェア（GPUやFPGAなど）を並列に並べて総当たりを高速化しようとする攻撃者にとって負担が大きくなります。コストの割に合わない試行になりやすいためです。OWASPの「Password Storage Cheat Sheet」は、優先度の高い順に次のアルゴリズムを挙げています。

これらはいずれも、汎用のハッシュ関数（SHA-256など）を単体で使う場合と比べ、意図的に計算コストを重くしている点が共通しています。専用のハッシュ関数を選ぶこと自体が、ストレッチングを取り入れる近道になるといえるでしょう。

注意したいのは、こうしたパスワード専用ハッシュ関数を、自前で一から実装する必要はない、という点です。主要なプログラミング言語やフレームワークには、標準ライブラリや広く使われる外部ライブラリが用意されています。Argon2・bcrypt・PBKDF2の実装も、その中にすでに含まれているのです。ソルトの生成やハッシュの検証まで含めて自作しようとすると、細部の実装ミスが保護の弱さにつながりやすいため、既存の実装を利用するのが手堅い進め方になります。開発を委託する際は、自作の暗号処理を避け、実績のあるライブラリを使う方針かどうかを確認するとよいでしょう。

発注・レビューで確認すべき保存方式

既存システムの保存方式を確認する

すでに稼働しているシステムでは、パスワードがどの方式で保存されているかを、まず確認する必要があります。平文保存や、ソルトを伴わない単純なハッシュ（MD5・SHA-1など）のまま残っている場合、レビューの優先度は高くなるでしょう。開発会社に保存方式を尋ね、資料やコードで裏付けを取ることが、発注側にできる確認作業のひとつです。

確認する際は、使用しているアルゴリズム名（Argon2・bcrypt・PBKDF2・SHA-256など）とソルトの有無を、まず尋ねるとよいでしょう。反復回数やメモリ使用量の設定値まで、できるだけ具体的に開発会社へ確認しておきたいところです。「ハッシュ化しています」という回答だけでは、平文保存でないことは分かっても、レインボーテーブルや総当たりへの備えができているかまでは判断できません。

弱い方式からの移行を計画する

保存方式を切り替える際、既存のハッシュ値をそのまま新しい方式へ変換することはできません。ハッシュは一方向の変換であるため、元のパスワードが分からないと、パスワード専用ハッシュ関数で作り直すことができないのです。実務では、利用者が次回ログインしたタイミングで新方式に作り替える、段階的な移行が採られます。

この移行には、旧方式のハッシュを一定期間残しておく設計や、パスワードリセットを促す運用など、複数の選択肢があります。どの方式を選ぶかによって、利用者への影響と開発工数のバランスは変わってくるはずです。委託先と移行方針をすり合わせておくことが、後戻りの少ない進め方につながります。

段階的な移行を進める場合の実務上の手順は、大まかに次の通りです。

1. 新しいパスワード専用ハッシュ関数（Argon2idなど）を実装し、新規登録者から適用する。
2. 既存利用者がログインした際、入力されたパスワードを新方式でハッシュ化し直し、保存を更新する。
3. 旧方式のまま長期間ログインがない利用者には、パスワードリセットを案内する。
4. 旧方式のハッシュがすべて置き換わったことを確認したうえで、旧方式に対応するコードを整理する。

この進め方であれば、利用者に一律のパスワード再設定を強いることなく、時間をかけて保存方式を切り替えられます。ただし、旧方式のまま残る期間が長くなるほど、その間のリスクは続くため、移行の期限や優先順位を委託先と決めておくことが欠かせません。

パスワードの取り扱い範囲を線引きする

保存方式だけでなく、パスワードを扱う範囲そのものを線引きしておくことも欠かせません。ログの出力にパスワードの平文が混ざっていないか、パスワードリセットの通知に新しいパスワードをそのまま記載していないかを確認します。保存以外の経路からの漏えいにも注意が必要です。管理者であってもパスワードそのものを閲覧できない設計にしておけば、内部からの持ち出しリスクも抑えられます。

開発環境やテスト環境に、本番相当のパスワードデータをそのまま複製していないかも、あわせて確認しておきたい点です。テスト用のダミーデータに置き換える、あるいは本番データを扱う環境へのアクセスを限られた担当者に絞るなど、対応の選択肢は複数あります。保存方式の設計と同じくらい、データの取り扱い範囲を線引きする運用ルールが実効性を左右するのです。

これらの確認には、認証まわりの実装経験とセキュリティ観点の両方が求められます。自社の担当者だけで全項目を洗い出すのがむずかしい場合は、外部の開発パートナーとレビュー体制を組むことも、現実的な選択肢のひとつでしょう。

ログイン試行の制限や多要素認証との役割分担を理解する

パスワードハッシュは、漏えいした後の被害を抑えるための対策です。漏えいそのものや不正ログインの試行を防ぐ役割は、別の仕組みが担っています。たとえば、一定回数ログインに失敗したアカウントを一時的にロックする仕組みは、総当たり攻撃をオンラインで直接試みる行為への備えです。パスワードに加えて別の要素を組み合わせる多要素認証は、パスワードそのものが漏えいした場合でも、不正ログインを成立させにくくする備えといえます。

発注担当者としては、パスワードの保存方式だけを見て認証まわりの対策が十分かどうかを判断しないことが大切です。保存方式・ログイン試行の制限・多要素認証は、それぞれ防ぐ対象が異なる、役割の違う対策の組み合わせです。企画・要件定義の段階でどこまで備えるかを開発パートナーとすり合わせておくと、後工程での手戻りを抑えやすくなります。

まとめ

• パスワードハッシュは、利用者のパスワードを元に戻せない形で保存し、漏えい時の被害を抑える仕組みである。
• 一方向ハッシュだけではレインボーテーブルや総当たり攻撃に弱く、ソルトを付与して同じパスワードでも異なる値にする対策が必要になる。
• ストレッチング（反復処理）とArgon2・bcryptなどのパスワード専用ハッシュ関数を組み合わせ、総当たりの試行速度を抑える。
• 発注・レビューでは、既存システムの保存方式の確認、弱い方式からの移行計画、パスワードの取り扱い範囲の線引きが論点になる。
• 保存方式の設計は、ログイン試行の制限や多要素認証といった別の認証対策と組み合わせて、はじめて全体の備えになる。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• OWASP Cheat Sheet Series「Password Storage Cheat Sheet」
• IPA（独立行政法人情報処理推進機構）「不正ログイン被害の原因となるパスワードの使い回しはNG」
• Wikipedia日本語版「ソルト (暗号)」
• Wikipedia日本語版「鍵導出関数」

Tweet