脆弱性コラム - 第11回
サイト脆弱性をチェックしよう！ -- 第11回 ：パスワードの暗号化保存について確認しよう
Webサイトが攻撃を受け、利用者のログインパスワードが漏洩したとの事例が度々報道されている。被害を受けないための根本的な対策は、攻撃の対象となる脆弱性を作り込まない・脆弱性を改修することだが、サイトに存在する何百のページすべてにおいて対策を徹底することは簡単ではない。また、システムが利用しているプロダクトに存在するゼロデイの脆弱性を悪用されてしまうなど、必ずしも根本的な対策を徹底できるとは限らない場合もある。万一それらの攻撃を受けてしまっても、パスワードそのものが漏洩しないための保険的な対策として、パスワードを暗号化して保存する方法がある。データベース上に何らかの方法で暗号化したパスワードを保存しておくことで、たとえ攻撃を受けて保存した情報がすべて漏洩してしまったとしても、そこに含まれるのは暗号化後のパスワードであり、パスワードそのものが漏洩したわけではないため、結果的に被害を軽減することができる。
今回は保険的な対策としてのログインパスワードの暗号化保存について、適切に実施する上で確認すべきポイントを記載しよう。
上記では「パスワード暗号化保存」と表現したが、厳密には「平文のパスワードを異なる文字列に変換して保存する方法」についての解説となる。
一般的には「平文のパスワードを変換」することを「暗号化」という単語を用いて表現することがあるが、本稿では「広義の暗号化」と呼称し、厳密な意味での暗号化を指す場合に「暗号化」という語を用いる。
暗号化とハッシュ化
広義の暗号化には主に下記2種の手法が存在し、それぞれに特徴がある。- 暗号化：鍵を用いて元のデータに復号することが可能な手法、また暗号化に使った鍵が異なれば、暗号アルゴリズムと元のデータが同じでも異なる変換結果になる
- ハッシュ化：元のデータには戻すことができない変換手法で、ハッシュアルゴリズムと元のデータが同じであれば、常に同一の変換結果になる
対してハッシュ化は、一度データを変換した後は計算などで機械的に元に戻す手段がない。そのため、元のデータが漏洩する機会を極力減らしたい場合且つ元のデータに復元する必要がない場合に用いられる。
Webサイトのログイン処理について
本稿ではWebサイトのログインパスワードを対象として記述するため、その処理について、ここで簡単に言及しておく。多くのWebサイトでは利用者がログイン画面にIDとパスワードを入力し、システム側でその組み合わせが正しくデータベース上に存在するかを確認してログイン可否を決定する仕組みとなっている。ただし、暗号化なりハッシュ化なりで変換したパスワードがデータベースに格納されていると、当然ながら画面の入力値とデータベース内の値を単純に比較しただけでは整合せず、ログイン失敗となってしまう。そのため、画面入力されたパスワードを、Webサイトのアプリケーションプログラム内でいったん受け取り、最初にデータベースにパスワードを格納する際（多くの場合は初回アカウント作成時）と同様のアルゴリズムを用いて変換し、変換後の入力パスワードとデータベース内の値とを比較してログイン可否を処理することになる。さて、Webサイトのログインパスワードを安全に保存する上で有効な手法は暗号化・ハッシュ化のどちらだろうか。それぞれの手法を用いた場合に、どのような特徴とリスクが存在するかを確認していこう。
暗号化の特徴とリスク
まずは暗号化の特徴とリスクについて検討してみよう。- 復号の必要性
暗号化の特徴として言及すべきは復号可能という点であるが、Webサイトのログインパスワードを保存する場合において、その利点とは何であろうか。パスワードを忘れてしまった利用者からの問い合わせに、鍵を知る管理者が利用者のパスワードを復号して対応する場合には活用できそうだ。しかし、現在多くのWebサイトで実装されているように、パスワード以外の何らかの方法で本人確認した上で、利用者本人に新しいパスワードを設定させることができれば用途として充分であり、Webサイトにおいては必ずしもログインパスワードの復号を必要とする要件はない。例外的にパスワードそのものを管理することが目的のWebサイト(*1) などは、パスワードを復号する要件が存在するが、それでもそのサイトのログインパスワード自体は同様に復号が必要な場面は存在しないと考えられる。(*2)
また、ログインが必要なWebサイトは、本人であることを認証するための要素としてパスワードを用いているので、本人以外にそれを知る者が存在すべきではなく、機密は知る者が少ないほど漏洩する危険性も少なくなることを考えると、例え管理者であっても利用者のパスワードを知る機会がない方が漏洩のリスクが減り、より安全であるといえる。 - 鍵の漏洩
暗号化のリスクとしては、鍵が漏洩するとパスワードが漏洩するリスクが高まることが挙げられる。暗号化済みのパスワードが漏洩してしまった際、鍵も同時に漏洩しなければ、たしかにパスワードそのものは漏洩しない。しかしながら、暗号化済みのパスワードが漏洩した原因がネットワークへの不正侵入や管理者権限の奪取だとすれば、鍵も同時に漏洩している可能性が高い。暗号化済みのパスワードは漏洩したが鍵は漏洩していないので実被害はないというケースは、SQLインジェクション攻撃など限定された場面であると見なすべきである。
例えどんな攻撃を受けても鍵だけは決して漏洩しない、という安全な保管方法があれば問題はないが、そのような手段は現実的には存在しないと考えるべきだ。保険的な対策としての安全なパスワード保存手段は、システム上に存在するすべての情報が漏洩した場合も想定した上で検討する必要がある。
以上のことから、暗号化はWebサイトにおける保険的な対策としての安全なパスワード保存手段に適しているとはいえず、かつ復号可能という利点を活かす場面も特に存在しないということになる。
(*1) 他の複数のシステムのパスワードを記録しておき、ログインすることで記録したパスワードを抽出できるシステム。推測されにくい複雑なパスワードを設定すると覚えにくいという懸念があるが、逆に覚えやすいものにすると第三者に推測されるリスクが増すため、その問題を解決するために利用される。代表的なサービスとしてはLastPassや1Passwordなどがある
(*2) 本稿ではシステムが取り扱うコンテンツとしてのパスワードではなく、そのシステムにログインするためのパスワードを対象として記述する
ハッシュ化の特徴とリスク
対してハッシュ化はどうであろうか。その特徴とリスクについて以下に記載する。- 復号できないことの利点
先に述べた通りハッシュ化したデータは、鍵などを使って元に戻すことはできない。そのため、パスワードをハッシュ化して保存していれば、例えWebサイトの管理者であっても利用者のパスワードを割り出す方法がなく、本人以外がパスワードを知り得る機会を低減できる。また、サーバへの侵入などデータベースの中身以外の情報も漏洩し得るような攻撃であっても、暗号鍵の漏洩から平文パスワードの漏洩に繋がるリスクがない。 - 逆引きのリスク
しかし、ハッシュ化したパスワードから元の平文パスワードを導き出す手段がまったくないわけではない。先に、ハッシュ化の特徴としてハッシュアルゴリズムと元のデータが同じであれば、常に同一の変換結果になると述べた。このため、パスワードに用いられる文字列をあらかじめハッシュ化した一覧表があれば、その表から漏洩したデータを逆引きすることで元のパスワードを割り出すことができてしまう。例えば下記は「最悪なパスワード トップ100」などとしてセキュリティ企業が発表しているパスワードの中から、上位ランクの（最悪に近い）パスワードとその文字列をSHA-1というアルゴリズムでハッシュ化した値を記載した表である。
例えば漏洩データの中に「ee8d8728f435fd550f83852aabab5234ce1da528」という値が見つかれば、ハッシュ化前の「iloveyou」という文字列を逆引き可能となり、これによりもとの平文パスワードが漏洩する。
上記は説明を簡略化するため4つの値のみ例示したが、パスワードを構成するすべての文字列の組み合わせを対象とした表を用意しておけば、理論上はハッシュ化されたすべてのパスワードを逆引きできる。
とはいえ、仮に英大文字・英小文字・数字の文字種で構成される計8文字のパスワードでさえ、その組み合わせは計200兆通り以上にもなり、このような膨大なデータ量を保存した表を運用することは現実的ではない。そのため、還元関数とチェイン化と呼ばれる特殊な技法を駆使して、データを保存するために必要な領域を圧縮したレインボーテーブルと呼ばれるデータベースが用いられる。このレインボーテーブルの悪用を前提とすれば、ハッシュ化して保存したパスワードであっても、平文のパスワードが漏洩するリスクが存在することになる。
- 総当たり攻撃のリスク
その他、総当たりでパスワード照合を試行する攻撃にもリスクが存在する。総当たり攻撃（ブルートフォースアタック）は、方法は単純だが試行回数と時間さえ掛ければ理論上必ず成功する手段である。ログイン画面で機械的にパスワード入力を試行する攻撃については、アカウントロック機能によって担保されるが、先述の通り、システムに存在するすべての情報が漏洩した場合を想定するならば、Webサイト上ではなく漏洩データを保存した攻撃者のローカル環境で総当たりされることを考慮する必要がある。ローカル環境での総当たり攻撃には試行回数の制限を課すことができないため、ハッシュ化したパスワードであってもいつかは必ず解析されてしまうリスクが存在する。
以上のように、単純なハッシュ化を施しただけでは保険的な対策としての安全なパスワード保存手段とはなり得ないといえる。
ここまでの整理
保険的な対策としての安全なパスワード保存手段の要件は、下記にまとめられる。- 利用者本人のみがパスワードを知り得る方式であること
- システム上の情報がすべて漏洩したとしても有効に機能すること
以上、保険的な対策としての安全なパスワード保存方法として要件と適切な方式について確認した。適切な保存方法についての詳細は、次回のコラムにおいて記述したいと思う。
イベント・セミナー
ニュース・キャンペーン
AppScanに
関するお問い合わせ
テクマトリックス株式会社
東京本社ネットワークセキュリティ事業部
第3営業部
セキュリティプロダクツ営業2課03-4405-7814
- メールでのお問い合わせ
- watchfire@techmatrix.co.jp