アカウント名:
パスワード:
アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。その安全神話によって思考停止しているので、最小8文字以上としながらも最大パスワード長は20文字以下しか認めないサイトのなんと多いことか・・・。20文字以下どころか、12文字以下しか認めない所の方が大半という体たらく。
パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。10代の若者に「パスワードを複雑化しろ」と要請するよりも、パスワードとして認められる最大長が20文字以下のクソサイトを吊るしあげる方が遥
ハッシュ関数にMD5を使っているならどれだけパスワードを長くしてもランダムな英数字約20文字、SHA1なら約25文字、SHA256なら約40文字より安全には絶対にならない。覚えやすくなるだけ(でも十分だしいずれにしても12文字は少なすぎるが)。パスワードに不可逆なハッシュ化をしていないとか暗号学的な検討のなされていないオレオレハッシュを使うのは別の意味で論外だし。辞書に載っている単語だけを組み合わせるならMD5で約11語、SHA1で約13語、SHA256で約21語の組み合わせ程度でいいけど、これは完全にランダムに単語を選んだ場合なのでパスフレーズジェネレーターでも使わない限りもう少し長くとったほうがよさそう。
まず、MD5 や SHA-1 は、そもそも暗号学的ハッシュ関数としての脆弱性が発見されているから、パスワードのハッシュ化に使うべきかどうかとの議論以前に、今では如何なる用途においても優位性がありません。転送中にファイルが破損(改ざんではなく通信中のノイズなどによる偶然の破損)したか調べる為には使えますが、だったら CRC32 などの方がより高速です。
そして、暗号学的ハッシュ関数として安全とされている SHA-2 (SHA-256 など) であっても、暗号学的高速ハッシュ関数はパスワードのハッシュ化に用いるべきではありません。これらは、高速にハッシュ値を求めるための関数であって、パスワードの保存に用いる為に開発されたものではないからです。詳しいことは、安全なパスワードハッシュ [php.net] が分かりやすいです。
もし、専門的知識があるなら、適切なソルトを付けたり、暗号学的高速ハッシュ関数を適切な回数通したり、各ユーザのハッシュをユニークにしたりするなど、自分で安全になるようなコードを書くことができるという考えもあるかもしれません。しかし、独自の暗号アルゴリズムを開発して厳重な秘密管理をするよりも公開されている安全とされるアルゴリズムを使うべきであるのと同様に、HMAC [wikipedia.org]、PBKDF2 [wikipedia.org]、Bcrypt [openwall.com] といったパスワードのハッシュ化に適しているスキームとして十分な検証がなされているものを用いるべきだと思います。
更に良いのは、password_hash [php.net] といったパスワードハッシュ専用の API を用いることです。パスワードのハッシュ化に適しているスキームとして十分な検証がなされているハッシュ関数(現在は bcrypt)が用いられますし、サーバーをベンチマークして適切な強度のストレッチングを行うことが簡単にできます。サーバのスペックが上がったらコード変更無しにストレッチング強度を自動的に高めるとか、負荷が少ない時間帯はストレッチングの強度をあげるといったことも簡単にできます。また、将来的により強力なアルゴリズムが現れれば php のアップデートで自動的にパスワードハッシュアルゴリズムが切り替わる仕様になっているので、古いプログラムコードが使われ続けていたとしても、安全性を維持することができます(データ長が将来的に増えることも想定されており、パスワードハッシュを格納するデータベースのデータ長に余裕を持たせることが推奨されています)。
ソルト導入すべしってのは当然だけど、ストレッチングは微妙だなぁ…攻撃側はGPGPUやFPGAで演算コストを抑えてるのに対して、防衛側は汎用CPUでそこそこの最適化しかしてない。防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
使えるのは余剰の演算コストだけと考えると深いストレッチも出来ないので結構辛い。
防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
確かに、1回のストレッチングにかかるコストという意味では、防御側より攻撃側の方が大幅に低いです。しかしながら、防御側はパスワードの認証・登録・変更が行われた時のみストレッチング処理を所定の回数行えば良いのに対して、攻撃側は総当たり攻撃のパターン数の分行わなければならないため、トータルでは攻撃側が支払うコストが上回っていると言えます。
具体的な例を挙げると、パスワードの認証(ログイン)・新規登録(アカウント追加)・パスワード変更の回数が1日1万回のシステムで、ストレッチングの回数が10万回の場合、防御側が行うストレッチング処理は10億回/日 です。それに対して、8桁のランダムな英数字のパスワードを破ろうとした場合、攻撃側は全通り試すならば 218,340,105,584,896 通り試す必要があるので、ストレッチング処理を 100,000 × 218,340,105,584,896 =21,834,010,558,489,600,000 (回) する必要があります。つまり、この場合(8桁のランダムな英数字のパスワードを全通り試す場合)、攻撃側は防御側の 21,834,010,558倍 (約200億倍) の処理コストがかかると言えます。
ちなみに、以前試算しましたが [srad.jp]、日本の理化学研究所のスパコン「京」のCPUで、まともなアルゴリズムでハッシュ化(HMACハッシュ関数によるストレッチングを含む)されているパスワードの解析を行う場合、1秒間に1万回しか試行できないという結果になりました。この場合、GPU演算は考慮していませんでしたが、攻撃側がNSAなどの巨大組織でない限り、GPGPUやFPGAを使ったとしてもスパコン「京」のCPU演算を超えるだけの能力をはじき出すのはなかなか難しいのではないでしょうか。
1秒間に1万回の試行であれば、ランダムな英数字8桁のパスワードの場合、平均で400年ぐらいの解読時間がかかることになります。従って、ユーザーが8桁のランダムな英数字、もしくはそれを超える安全性のパスワード(ランダムな英単語4個 : copy-item-tokyo-heavy など)を使ってくれるという前提においては、ストレッチングは「急場凌ぎの対処法」ではなく「解決法」と言えると思います。
オフトピ。
MD5, SHA1って。。。。すでに2007年の時点で ありがとうそしてさようなら [google.com]という認識でいたのですが、今でも大事にされているんですか?そうわりきるしかないという現状を憂えているということですね、きっと。
それにしてはSHA-2(SHA-256)への移行がまだゆるゆる進んでいないみたいだし、そもそも今の若い人(a.k.a. 労害労害いう人)が引退するころにはそれも破られているだろうし。。。
探索時間で考えるならハッシュ空間全部使いきらなくても良い気がするとか考えるのはヘタレでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
逆に危険 (スコア:4, すばらしい洞察)
アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。
その安全神話によって思考停止しているので、最小8文字以上としながらも最大パスワード長は20文字以下しか認めないサイトのなんと多いことか・・・。
20文字以下どころか、12文字以下しか認めない所の方が大半という体たらく。
パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。
10代の若者に「パスワードを複雑化しろ」と要請するよりも、パスワードとして認められる最大長が20文字以下のクソサイトを吊るしあげる方が遥
Re:逆に危険 (スコア:0, オフトピック)
ハッシュ関数にMD5を使っているならどれだけパスワードを長くしてもランダムな英数字約20文字、SHA1なら約25文字、SHA256なら約40文字より安全には絶対にならない。覚えやすくなるだけ(でも十分だしいずれにしても12文字は少なすぎるが)。パスワードに不可逆なハッシュ化をしていないとか暗号学的な検討のなされていないオレオレハッシュを使うのは別の意味で論外だし。
辞書に載っている単語だけを組み合わせるならMD5で約11語、SHA1で約13語、SHA256で約21語の組み合わせ程度でいいけど、これは完全にランダムに単語を選んだ場合なのでパスフレーズジェネレーターでも使わない限りもう少し長くとったほうがよさそう。
パスワードハッシュ専用の API を用いるべき (スコア:5, 興味深い)
まず、MD5 や SHA-1 は、そもそも暗号学的ハッシュ関数としての脆弱性が発見されているから、パスワードのハッシュ化に使うべきかどうかとの議論以前に、今では如何なる用途においても優位性がありません。転送中にファイルが破損(改ざんではなく通信中のノイズなどによる偶然の破損)したか調べる為には使えますが、だったら CRC32 などの方がより高速です。
そして、暗号学的ハッシュ関数として安全とされている SHA-2 (SHA-256 など) であっても、暗号学的高速ハッシュ関数はパスワードのハッシュ化に用いるべきではありません。これらは、高速にハッシュ値を求めるための関数であって、パスワードの保存に用いる為に開発されたものではないからです。詳しいことは、安全なパスワードハッシュ [php.net] が分かりやすいです。
もし、専門的知識があるなら、適切なソルトを付けたり、暗号学的高速ハッシュ関数を適切な回数通したり、各ユーザのハッシュをユニークにしたりするなど、自分で安全になるようなコードを書くことができるという考えもあるかもしれません。しかし、独自の暗号アルゴリズムを開発して厳重な秘密管理をするよりも公開されている安全とされるアルゴリズムを使うべきであるのと同様に、HMAC [wikipedia.org]、PBKDF2 [wikipedia.org]、Bcrypt [openwall.com] といったパスワードのハッシュ化に適しているスキームとして十分な検証がなされているものを用いるべきだと思います。
更に良いのは、password_hash [php.net] といったパスワードハッシュ専用の API を用いることです。パスワードのハッシュ化に適しているスキームとして十分な検証がなされているハッシュ関数(現在は bcrypt)が用いられますし、サーバーをベンチマークして適切な強度のストレッチングを行うことが簡単にできます。サーバのスペックが上がったらコード変更無しにストレッチング強度を自動的に高めるとか、負荷が少ない時間帯はストレッチングの強度をあげるといったことも簡単にできます。また、将来的により強力なアルゴリズムが現れれば php のアップデートで自動的にパスワードハッシュアルゴリズムが切り替わる仕様になっているので、古いプログラムコードが使われ続けていたとしても、安全性を維持することができます(データ長が将来的に増えることも想定されており、パスワードハッシュを格納するデータベースのデータ長に余裕を持たせることが推奨されています)。
Re: (スコア:0)
ソルト導入すべしってのは当然だけど、ストレッチングは微妙だなぁ…
攻撃側はGPGPUやFPGAで演算コストを抑えてるのに対して、防衛側は汎用CPUでそこそこの最適化しかしてない。
防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
使えるのは余剰の演算コストだけと考えると深いストレッチも出来ないので結構辛い。
トータルでは攻撃側の支払うコストの方が大きい (スコア:5, 興味深い)
確かに、1回のストレッチングにかかるコストという意味では、防御側より攻撃側の方が大幅に低いです。しかしながら、防御側はパスワードの認証・登録・変更が行われた時のみストレッチング処理を所定の回数行えば良いのに対して、攻撃側は総当たり攻撃のパターン数の分行わなければならないため、トータルでは攻撃側が支払うコストが上回っていると言えます。
具体的な例を挙げると、パスワードの認証(ログイン)・新規登録(アカウント追加)・パスワード変更の回数が1日1万回のシステムで、ストレッチングの回数が10万回の場合、防御側が行うストレッチング処理は10億回/日 です。それに対して、8桁のランダムな英数字のパスワードを破ろうとした場合、攻撃側は全通り試すならば 218,340,105,584,896 通り試す必要があるので、ストレッチング処理を 100,000 × 218,340,105,584,896 =21,834,010,558,489,600,000 (回) する必要があります。つまり、この場合(8桁のランダムな英数字のパスワードを全通り試す場合)、攻撃側は防御側の 21,834,010,558倍 (約200億倍) の処理コストがかかると言えます。
ちなみに、以前試算しましたが [srad.jp]、日本の理化学研究所のスパコン「京」のCPUで、まともなアルゴリズムでハッシュ化(HMACハッシュ関数によるストレッチングを含む)されているパスワードの解析を行う場合、1秒間に1万回しか試行できないという結果になりました。この場合、GPU演算は考慮していませんでしたが、攻撃側がNSAなどの巨大組織でない限り、GPGPUやFPGAを使ったとしてもスパコン「京」のCPU演算を超えるだけの能力をはじき出すのはなかなか難しいのではないでしょうか。
1秒間に1万回の試行であれば、ランダムな英数字8桁のパスワードの場合、平均で400年ぐらいの解読時間がかかることになります。従って、ユーザーが8桁のランダムな英数字、もしくはそれを超える安全性のパスワード(ランダムな英単語4個 : copy-item-tokyo-heavy など)を使ってくれるという前提においては、ストレッチングは「急場凌ぎの対処法」ではなく「解決法」と言えると思います。
Re:逆に危険 (スコア:1)
オフトピ。
MD5, SHA1って。。。。
すでに2007年の時点で ありがとうそしてさようなら [google.com]
という認識でいたのですが、今でも大事にされているんですか?
そうわりきるしかないという現状を憂えているということですね、きっと。
それにしてはSHA-2(SHA-256)への移行がまだゆるゆる進んでいないみたいだし、
そもそも今の若い人(a.k.a. 労害労害いう人)が引退するころにはそれも破られているだろうし。。。
Re: (スコア:0)
探索時間で考えるならハッシュ空間全部使いきらなくても良い気がするとか考えるのはヘタレでしょうか?