パスワードハッシュを実装する方法について、SOに関する多くの投稿を読みました。そして、パスワードを何度もハッシュ化するべきではないことを読みました (まあ、それはあまり役に立たないと言われています)。しかし、なぜですか？ハッシュ化されたパスワードを 10,000,000 回繰り返すとします (ユーザーは登録が完了するまで 3 秒待つか、AJAX 要求を送信することでそれを行うことができるため)。
では、攻撃者がどのようにして私のデータベースを盗み、私がパスワードを 10,000,000 回繰り返していることを知っていたとしても (最悪のシナリオ)、ユーザーのパスワードを突き止めることができるのでしょうか? 彼はレインボー テーブルを作成できませんでした。非常に時間がかかるためです (パスワードのハッシュには時間がかかり、ハッシュを何度もハッシュするにはさらに時間がかかります)。ブルート フォースも実際には不可能です。
夕方: bcrypt や PBKDF については何も言っていません。
あなたの質問は、「彼らの方法をうまく模倣することによって、bcrypt/PBKDFを使用しなければならないことを回避しようとしています」と暗黙のうちに叫びます。ただし、重複した質問で提起された問題は、単にキーを X 回再ハッシュするのではなく、これらの新しいアルゴリズムが考案された理由です。
簡単な答えが欲しいですか？次に：はい。X+1 ハッシュ ラウンドは、X ハッシュ ラウンドよりも安全ですが、ほんのわずかです。ループすることで、サーバー上でハッシュを計算するのに 1 ～ 2 秒かかるかもしれませ$hash = hash('sha512', $hash);ん。いくつかの AWS インスタンス、グラフィックス カードのファーム、またはボットネットにまたがる攻撃。
PBKDF と bcrypt が採用する方法は、スライド攻撃の影響を最小限に抑える/無効にするためのかなりの方法であり、bcrypt はある種の魔法のブードゥーを実行して、ある程度並列化できないようにします。
パスワードのハッシュ化、ハッシュのハッシュ化、そのハッシュのハッシュ化などについて話していると仮定しています。ハッシュ値をハッシュオブハッシュ値にマップするだけのレインボーテーブルを簡単に作成できます。
したがって、HASH(PASSWORD) = H で、HASH(H) = H1、HASH(H1) = H2 などの場合、簡単にダウンロードできるレインボー テーブルに PASSWORD | のようなリストを含めることができます。H とその方法でパスワードを逆引きします。さらに、H | のようなファイルがあります。H10000 とその逆も同様です。
だから、あなたはハッカーに迷惑をかけたのかもしれません。しかし、実際には「より安全」というわけではありません。なぜなら、それはより長い道のりであり、より危険で困難なものではないからです。