アナーキーなインターネットグループ「Anonymous」が先頃、HBGary Federalとルートキットテクノロジの分析と開発に専心しているオンラインフォーラム「rootkit.com」をハッキングした。「rootkit.com」の全ユーザパスワードに障害が起きている。
この件に関連して、アプリケーションセキュリティで気に入っているトピック、すなわちパスワードハッシュについて指摘したい。

Web(およびその他の)アプリケーションが、ユーザパスワードのハッシュにMD5、SHA1またはSHA-256を使用しており、先進的なデベロッパさえ、そのパスワードをsaltしている。そして私は長年に渡って、salt値はどのように生成されるべきか、どのくらいの長さであるべきかについて、白熱した議論を目にしてきた。
残念なことに、ほとんどの場合、MDおよびSHAハッシュファミリーは計算速度のために設計されており、そして「rootkit.com」で起こったように、salt値のクオリティは、攻撃者が完全なコントロールを握ったとき、重要ではないという事実が見逃されている。攻撃者がルートアクセスを有するとき、彼らはあなたのパスワード、saltおよびあなたがパスワードを確認するために使用するコードを獲得する。
そして、どんなセキュリティ設計でも基づくべき推測は、攻撃者がサーバ上のすべてにアクセス可能である、ということだ。
saltは主として、レインボーテーブルとしても知られる、事前計算された攻撃を防止することを目的としている。そして事前計算された攻撃が防止される限り、たとえ攻撃者がユーザパスワードと共にsalt値を獲得したとしても、パスワードは比較的安全だと、一般に推測されてきた。
しかしMDおよびSHAハッシュバリアントは、計算速度のために設計されており、これは、処理用のビデオグラフィックスディスプレイカードを使用すると、攻撃者が1秒に何億ものブルートフォースを容易に試みることができるということを意味する。
以下を参照:http://www.golubev.com/hashgpu.htm
すなわち、単一のATI HD 5970でさえ、攻撃者は33日で典型的レインボーテーブル(2^52.5ハッシュ)に相当するパスワードスペースをカバーすることができる、ということを意味している。そしてシリアスな攻撃者が、仕事に複数のカードを使用していることは間違いない。
攻撃者があなたのsalt値とコードを獲得した場合、ユーザアカウントを保護するものは、使用されているパスワードの強度しかないが、我々はあまり、エントロピーの良いソースであるとは言えない。辞書攻撃とブルートフォースの手法を組み合わせることによって、多くのアカウントを持つ大規模サイトであっても、かなりの量のパスワードを破るのに、それほど長い時間はかからないだろう。
このような事態を避けるには、どうすべきだろう?
最初に考えるべきことは、パスワードが現実世界の金庫に非常に似ているということだ。重要なのは、中身を守る金庫を開けるのに必要なコードの長さだけでなく、開けるのにどのくらいの時間が掛かるかということだ。
これは、SHA1あるいは他のプレーンなハッシュアルゴリズムは明らかに、セキュアなパスワード認証向きではないことを意味している。
我々が使いたいのは、ブルートフォースに対して無力でないものだ。1秒あたり23億回の試みを行う代わりに、あなたは攻撃者を10,000回あるいは100,000回の試みに制限する何かを望むだろう。
そしてsalt値の使用は適切なインプリメンテーションに不可欠であるものの、あなたの問題を解決する確実な方法ではないのだ。
それには、以下のプロパティを満たすパスワードハッシュスキームが必要だ:
• 処理パワーが増大した場合、必要とされる計算時間を容易に調節することができる。
• 各ユーザが反復の固有番号を持つことができる。
• 各ユーザハッシュがユニークであり、2人のユーザが同じパスワードであるかを、ハッシュを比較して知ることが不可能である。
以下から、こうしたスキームをいくつか選ぶことができる:
• PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
• Bcrypt http://www.openwall.com/crypt/
• HMAC http://en.wikipedia.org/wiki/HMAC
各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。
よって、あなたがパスワードを扱っているなら、上記のスキームのうち1つを選び、望ましい時間(10、200msなど)内にサーバがパスワードをチェックする反復の回数を決定し、それを使用する。攻撃者が各反復で全アカウントに対して試せるようにするのではなく、各アカウントに個別にフォーカスさせるよう、各ユーザに対してユニークなsalt値と反復カウントを用意することだ。
この件に関連して、アプリケーションセキュリティで気に入っているトピック、すなわちパスワードハッシュについて指摘したい。

Web(およびその他の)アプリケーションが、ユーザパスワードのハッシュにMD5、SHA1またはSHA-256を使用しており、先進的なデベロッパさえ、そのパスワードをsaltしている。そして私は長年に渡って、salt値はどのように生成されるべきか、どのくらいの長さであるべきかについて、白熱した議論を目にしてきた。
残念なことに、ほとんどの場合、MDおよびSHAハッシュファミリーは計算速度のために設計されており、そして「rootkit.com」で起こったように、salt値のクオリティは、攻撃者が完全なコントロールを握ったとき、重要ではないという事実が見逃されている。攻撃者がルートアクセスを有するとき、彼らはあなたのパスワード、saltおよびあなたがパスワードを確認するために使用するコードを獲得する。
そして、どんなセキュリティ設計でも基づくべき推測は、攻撃者がサーバ上のすべてにアクセス可能である、ということだ。
saltは主として、レインボーテーブルとしても知られる、事前計算された攻撃を防止することを目的としている。そして事前計算された攻撃が防止される限り、たとえ攻撃者がユーザパスワードと共にsalt値を獲得したとしても、パスワードは比較的安全だと、一般に推測されてきた。
しかしMDおよびSHAハッシュバリアントは、計算速度のために設計されており、これは、処理用のビデオグラフィックスディスプレイカードを使用すると、攻撃者が1秒に何億ものブルートフォースを容易に試みることができるということを意味する。
以下を参照:http://www.golubev.com/hashgpu.htm
すなわち、単一のATI HD 5970でさえ、攻撃者は33日で典型的レインボーテーブル(2^52.5ハッシュ)に相当するパスワードスペースをカバーすることができる、ということを意味している。そしてシリアスな攻撃者が、仕事に複数のカードを使用していることは間違いない。
攻撃者があなたのsalt値とコードを獲得した場合、ユーザアカウントを保護するものは、使用されているパスワードの強度しかないが、我々はあまり、エントロピーの良いソースであるとは言えない。辞書攻撃とブルートフォースの手法を組み合わせることによって、多くのアカウントを持つ大規模サイトであっても、かなりの量のパスワードを破るのに、それほど長い時間はかからないだろう。
このような事態を避けるには、どうすべきだろう?
最初に考えるべきことは、パスワードが現実世界の金庫に非常に似ているということだ。重要なのは、中身を守る金庫を開けるのに必要なコードの長さだけでなく、開けるのにどのくらいの時間が掛かるかということだ。
これは、SHA1あるいは他のプレーンなハッシュアルゴリズムは明らかに、セキュアなパスワード認証向きではないことを意味している。
我々が使いたいのは、ブルートフォースに対して無力でないものだ。1秒あたり23億回の試みを行う代わりに、あなたは攻撃者を10,000回あるいは100,000回の試みに制限する何かを望むだろう。
そしてsalt値の使用は適切なインプリメンテーションに不可欠であるものの、あなたの問題を解決する確実な方法ではないのだ。
それには、以下のプロパティを満たすパスワードハッシュスキームが必要だ:
• 処理パワーが増大した場合、必要とされる計算時間を容易に調節することができる。
• 各ユーザが反復の固有番号を持つことができる。
• 各ユーザハッシュがユニークであり、2人のユーザが同じパスワードであるかを、ハッシュを比較して知ることが不可能である。
以下から、こうしたスキームをいくつか選ぶことができる:
• PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
• Bcrypt http://www.openwall.com/crypt/
• HMAC http://en.wikipedia.org/wiki/HMAC
各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。
よって、あなたがパスワードを扱っているなら、上記のスキームのうち1つを選び、望ましい時間(10、200msなど)内にサーバがパスワードをチェックする反復の回数を決定し、それを使用する。攻撃者が各反復で全アカウントに対して試せるようにするのではなく、各アカウントに個別にフォーカスさせるよう、各ユーザに対してユニークなsalt値と反復カウントを用意することだ。