目次
パスワード管理の仕組み
パスワードを安全に管理するためには、ソルトとストレッチングを用いてハッシュ値（暗号学的ハッシュ関数）としてデータベースに保存しておく必要があります。
本記事では
- パスワードはどのように管理されているのか？
- なぜパスワードはハッシュ値で保管する必要があるのか？
- ハッシュ値のパスワードを狙うサイバー攻撃とは？
- なぜソルトやストレッチングが必要なのか？
について図解で分かりやすく解説していきます。
スポンサーリンク
パスワードはどのように管理されているのか？
【アカウント登録】パスワードの入力
パスワード管理は、アカウント登録から始まります。
利用者が利用したいサイトにパスワードを入力してアカウント登録を行います。アカウント登録時の通信は TLS/SSL（HTTPS）により暗号化されていることが一般的です。
【アカウント登録】パスワードの保管
Webサーバは、利用者が入力したパスワードをハッシュ関数でハッシュ値へと変換します。そして、データベースには変換したハッシュ値を保存します。
【ログイン】パスワードの入力
アカウント登録が完了した利用者は、ログイン画面からパスワードを入力してログインします。アカウント登録時同様にログイン時の通信も TLS/SSL（HTTPS）により暗号化されていることが一般的です。
【ログイン】パスワードの比較
Webサーバは、利用者が入力したパスワードをハッシュ関数でハッシュ値へと変換します。
そして、変換したハッシュ値とアカウント登録時にデータベースに保管したハッシュ値を比較します。比較した結果、ハッシュ値が一致していれば、入力されたパスワードが正しいことが分かります。
※ハッシュ関数は入力値のデータが同じであれば、必ず同じハッシュ値を生成します。
なぜパスワードはハッシュ値で保管する必要があるのか？
パスワードを保管する方法には次の3つが考えられます。
- 平文のまま保管する
- 暗号文で保管する
- ハッシュ値で保管する
この3通りのパターンでパスワードを保管していたとして、仮にパスワードが情報漏洩してしまった場合、どうなってしまうでしょうか。次の図はそのイメージ図です。
平文でパスワードを保管していた場合に情報漏洩が発生したらパスワードは丸見えです。情報漏洩した時点で情報セキュリティ事故ですが、セキュリティ対策がまったくされていない大問題といえる情報セキュリティ事故です。
スポンサーリンク
次に暗号文で保管していた場合です。暗号化と復号は「鍵」で平文を暗号文に暗号化したり、暗号文を平文に戻したり（復号）できます。暗号文は元に戻すことが前提なのです。
パスワードが情報漏洩した時点で、もしかしたら「鍵」も漏洩しているかもしれません。パスワードを暗号文で保管するのは十分な対策とはいえません。
最後にハッシュ値で保管する場合です。ハッシュ値を生成するハッシュ関数は、ハッシュ値への変換は簡単に計算できるが、元に戻すことは非常に困難である「一方向性関数」です。
元に戻すことを前提としている暗号文とは違い、ハッシュ値は元に戻すことを前提としていません。古いハッシュ関数である MD5 や SHA-1 は脆弱性が見つかっていますが、脆弱性が見つかっていないSHA-2 や SHA-3でハッシュ値へと変換した値を元に戻すことは非常に困難であり、事実上不可能といえます。
ハッシュ値のパスワードを狙うサイバー攻撃とは？
ハッシュ値で保管したパスワードが、仮に外部へ情報漏洩した場合、主に次のような攻撃手法でハッシュ値から元のデータを推測できます。
辞書攻撃
辞書攻撃とは、辞書に載っている単語や単語の組み合わせからパスワードの候補を作り、その候補を片っ端から試すことによりパスワードを破ろうとする手法です。
ハッシュ値から元のデータを推測することは非常に困難ですが、弱いパスワード（推測しやすい短い単語など） の場合、辞書に載っている単語や単語の組み合わせをハッシュ値へと変換し、不正入手したハッシュ値と比較することで、元のデータを推測することが可能です。
総当り攻撃（ブルートフォース攻撃）
ブルートフォースとは「力ずくで」という意味で、別名「総当たり攻撃」とも呼ばれているパスワードを破る手法の一つです。
「力ずくで」そして「総当たり攻撃」の名前の通り、パスワードに使用されていると想定される文字列を1つずつ試していくことで、パスワードを破る手法です。
ハッシュ値から元のデータを推測することは非常に困難ですが、弱いパスワード（推測しやすい短いパスワードなど） の場合、総当たり攻撃で、十分な時間をかければ元のパスワードを推測することが可能です。
スポンサーリンク
レインボーテーブル攻撃
レインボーテーブル とは、特殊なテーブルを使いハッシュ値から元のデータ（平文）を導き出すための手法です。
ハッシュ関数と還元関数の2種類の関数を使い「平文」と「ハッシュ値」とのペアを「チェイン化」し、特殊なテーブルを作成します。そして、不正入手したハッシュ値の元データを推測していきます。
レインボーテーブル攻撃の詳細はこちらの記事をご覧ください。
なぜソルトやストレッチングが必要なのか？
ハッシュ値でパスワードを保管するだけでは、辞書攻撃、総当たり攻撃、レインボーテーブル攻撃などで元のデータを推測される危険性があります。
そこで辞書攻撃、総当たり攻撃、レインボーテーブル攻撃などの攻撃でも元のデータが推測できないように、ソルトとストレッチングを実施します。
ソルト（salt）とは
元に戻すことが困難であるハッシュ値を用いても、弱いパスワード（推測しやすい文字や短いパスワードなど）は、十分な時間をかければ元のデータを推測されてしまう危険性があります。
そのため、強いパスワードを利用者に設定してもらうことが理想ですが、パスワードが複雑すぎるとパスワードを忘れてしまったり、利用者の利便性を失う恐れもあります。
そこで、ソルト（salt）と呼ばれるランダムなデータをパスワードに連結してから、ハッシュ化します。
ソルトを付与することで、レインボーテーブル攻撃を回避することができます。ただし、ソルトを毎回同じ固定値で設定している場合、そのソルトを使い新しいレインボーテーブルを生成することができるため、ソルトは固定値ではなく、ユーザー毎にランダムな値で生成することが望ましいとされています。
次の図はソルトを利用したアカウント登録時のイメージ図です。利用者が入力したパスワードにソルトを付与してからハッシュ値へと変換しています。
次の図はソルトを利用したログイン時のイメージ図です。アカウント登録時に使用したソルトを入力データのパスワードに付与してハッシュ化、そして、データベースに保存してるハッシュ値と一致するか比較します。
ストレッチングとは
ただでさえ元に戻すことが困難であるハッシュ関数にソルトを付与するだけでも十分な対策ですが、それでもなお、弱いパスワードや文字数が長くないパスワードは、十分な時間をかければ元のデータを推測されてしまう可能性があります。
そこで実施するのが、ストレッチングです。ストレッチングとはハッシュ値の計算を数千回～数万回繰り返し行うことです。
ストレッチングは回数が多いほど解析が困難になるも、サーバ負荷が増えるというデメリットもあるため、ストレッチングの回数は、サーバ負荷を考慮して検討する必要があります。