セキュリティを向上させるために MD5 でユーザーのパスワードを複数回暗号化する人を見ました。これが機能するかどうかはわかりませんが、見栄えがよくありません。それで、それは理にかなっていますか?
4 に答える
使用するハッシュ関数が完全な一方向関数であると仮定しましょう。次に、 「ランダムなオラクル」のような出力を表示できます。その出力値は、値の有限範囲内にあります (MD5 の場合は 2^128)。
ハッシュを複数回適用するとどうなるでしょうか。出力は同じ範囲 (2^128) のままです。「私の乱数を推測してください!」と言っているようなものです。20 回、毎回新しい数字を考えます。だからと言って、推測が難しくなったり簡単になったりすることはありません。ランダムよりも「よりランダム」なものはありません。これは完全な例えではありませんが、問題を説明するのに役立つと思います。
パスワードの総当りを考慮すると、あなたのスキームはセキュリティをまったく追加しません。さらに悪いことに、「達成」できる唯一のことは、ハッシュ関数の繰り返し適用を悪用する可能性を導入することによってセキュリティを弱めることです。可能性は低いですが、少なくとも何も勝てないことは保証されています。
では、なぜこのアプローチですべてが失われるわけではないのでしょうか? これは、20回ではなく数千回の反復を行うことに関して他の人が作成した概念によるものです。アルゴリズムを遅くすることはなぜ良いことなのでしょうか? これは、ほとんどの攻撃者が辞書 (または頻繁に使用されるパスワードを使用してレインボー テーブル) を使用してアクセスしようとするためです。ユーザーの 1 人がそれらのいずれかを使用するのに十分な過失があることを期待しています (私は有罪です、少なくとも Ubuntu はインストール時に教えてくれました)。 . しかしその一方で、たとえば 30 のランダムな文字を覚えておくようにユーザーに要求するのは非人道的です。
そのため、パスワードを覚えやすくすると同時に、攻撃者がパスワードを推測するのをできるだけ難しくするという、ある種のトレードオフが必要です。2 つの一般的な方法があります。ソルトと、単一の反復ではなく、関数の多数の反復を適用してプロセスを遅くすることです。PKCS#5は、調べるのに適した例です。
あなたの場合、MD5 20000 を 20 回ではなく適用すると、辞書を使用する攻撃者の速度が大幅に低下します。これは、入力パスワードのそれぞれが、攻撃として引き続き有用であるために 20000 回ハッシュされるという通常の手順を実行する必要があるためです。この手順は、上に示したブルート フォーシングには影響しないことに注意してください。
しかし、なぜ塩を使った方が良いのでしょうか? ハッシュを 20000 回適用したとしても、機知に富んだ攻撃者はパスワードの大規模なデータベースを事前に計算し、それぞれを 20000 回ハッシュして、特にアプリケーションを対象としたカスタマイズされたレインボー テーブルを効果的に生成する可能性があるためです。これを行うと、彼らはあなたのアプリケーションまたはあなたのスキームを使用する他のアプリケーションを非常に簡単に攻撃することができます. そのため、このようなレインボー テーブルを実用的でなくするために、パスワードごとに高いコストを生成する必要もあります。
本当に安全を確保したい場合は、PKCS#5 に示されている PBKDF2 のようなものを使用してください。
パスワードのハッシュは暗号化ではありません。これは一方通行のプロセスです。
security.stackexchange.comとパスワード関連の質問を確認してください。それらは非常に人気があり、個人が有用な質問と回答を見つけるのに役立つように、このブログ投稿をまとめました.
この質問では、md5 を 20 回連続して使用することについて具体的に説明しています。Thomas Pornin の回答をご覧ください。彼の答えの要点:
- 20 は低すぎます。20000 以上にする必要があります - パスワード処理はまだ速すぎます
- 塩はありません: 攻撃者は非常に低いパスワードごとのコストでパスワードを攻撃する可能性があります。
- 特定のアルゴリズムが安全かどうかを確認するための確実なテストがないため、独自の暗号化を発明することは、多くの場合、災害のレシピとなります。やらないで
crypto.SE にはそのような質問がありますが、現在は公開されていません。Paŭlo Ebermannによる答え は次のとおりです。
パスワードハッシュには、通常の暗号化ハッシュを使用しないでください。bcrypt など、パスワードを保護するために特別に作成されたものを使用してください。
詳細については、パスワードを安全に保管する方法を参照してください。
重要な点は、パスワード クラッカーはハッシュ出力スペース (SHA-1 の場合は 2 160 ) をブルートフォースする必要はなく、はるかに小さいパスワード スペースだけであるということです (パスワード ルールによって異なりますが、多くの場合、辞書が役立ちます)。したがって、高速 なハッシュ関数ではなく、低速なハッシュ関数が必要です。Bcrypt とその仲間は、このために設計されています。
同様の質問には次の回答があります。質問は「暗号解読のブレークスルーに対する防御: 複数のハッシュ関数の組み合わせ」です。Thomas Porninによる回答:
結合は、SSL/TLSが MD5 と SHA-1 を使用して行うことであり、内部の「PRF」(実際にはKey Derivation Function ) の定義で行われます。特定のハッシュ関数について、TLS はハッシュ関数に依存する HMAC に依存する KDF を定義します。次に、KDF が 2 回 (MD5 で 1 回、SHA-1 で 1 回) 呼び出され、結果が XOR 演算されます。そのアイデアは、MD5 または SHA-1 のいずれかでの暗号解読の中断に抵抗することでした。2 つのハッシュ関数の出力を XOR することは、微妙な仮定に依存していることに注意してください。たとえば、固定定数Cに対して SHB-256( m ) = SHA-256( m ) XOR Cを定義すると、SHB-256 は SHA-256 と同じくらい優れたハッシュ関数になります。ただし、両方の XOR は常に Cを生成します、ハッシュの目的にはまったく適していません。したがって、TLS の構築は、科学の権威によって実際に認可されているわけではありません (たまたま壊れていないだけです)。TLS-1.2はその組み合わせを使用しなくなりました。多くの場合SHA-256(2011年には賢明な選択です)である単一の構成可能なハッシュ関数を持つKDFに依存しています。
@PulpSpy が指摘しているように、連結はハッシュ関数を構築する一般的な方法ではありません。これは 2004 年に Joux によって公開され、2006 年に Hoch と Shamirによって、反復と連結を含む大規模なクラスの構築のために一般化されました。ただし、細字に注意してください。これは、実際にはハッシュ関数の弱点を乗り切ることではなく、お金の価値を得ることです。つまり、128 ビット出力のハッシュ関数と 160 ビット出力の別のハッシュ関数を取り、その結果を連結すると、衝突耐性は 2 つのうち最も強いものより悪くはありません。Jouxが示したのは、それもそれほど良くならないということです. 128+160 = 288 ビットの出力では、2 144の抵抗を目指すことができますが、Joux の結果は、約 2 87を超えないことを意味します。
したがって、問題は次のようになります: 可能であれば効率的な 方法で、2 つのハッシュ関数を組み合わせて、結果が 2 つのハッシュ関数の中で最も強いものと同じくらい衝突耐性が高くなるようにする方法はありますが、連結の出力拡大を招くことはありませんか? 2006 年、Boneh と Boyenは、各ハッシュ関数を 1 回だけ評価するという条件に従って、答えはノーであると単純に述べた結果を発表しました。編集: Pietrzakは 2007 年に後者の条件を解除しました (つまり、各ハッシュ関数を数回呼び出すことは役に立ちません)。
そしてPulpSpyによる:
@Thomasが徹底的な答えをくれると確信しています。中間では、最初の構造 H1(m)||H2(M) の衝突耐性は、驚くべきことに H1(M) よりもそれほど優れていないことを指摘します。このペーパーのセクション 4 を参照してください。
http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
いいえ、それは良い習慣ではありません。暗号化には $salt を使用する必要があります。これらのレインボー テーブルでパスワードが解読される可能性があるためです。