-2

さて、ハッシュの全体的な問題は、ユーザーが15文字を超えるパスワードを入力しないことです。ほとんどの場合、4〜8文字しか使用しないため、攻撃者はレインボーテーブルで簡単にクラックできます。

解決策として、ユーザーソルトを使用してハッシュ入力をより複雑にし、50文字を超えて、テーブルを生成できないようにします（そのサイズの文字列では大きくなります）。さらに、ユーザーごとに新しいテーブルを作成する必要があります。問題：彼らがデータベースをダウンロードした場合、彼らはユーザーソルトを取得するので、彼らが十分に気にかけているなら、あなたは正方形に戻ります。

解決策として、サイト「pepper」とユーザーソルトを使用します。そうすれば、DBを取得したとしても、構成ファイルを知っている必要があります。問題：彼らがあなたのDBに侵入する可能性がある場合、彼らはあなたのファイルシステムに侵入し、あなたのサイトのコショウを発見するかもしれません。

したがって、これらすべてがわかっているので、攻撃者がサイトに侵入し、すべてを取得したと仮定しましょう。それで、あなたは今何をしますか？

議論のこの時点で、ほとんどの人は「この時点で誰が気にしますか？」と答えます。しかし、それは「次に何をすべきかわからないので、それほど重要ではない」という簡単な言い方です。悲しいことに、他のどこでも私は答えであるこの質問をしました。これは、ほとんどのプログラマーが非常に重要な点を見逃していることを示しています。

あなたのサイトが他の95％のサイトと同じであり、ユーザーデータ（または完全なサーバーアクセスさえも）はしゃがむ価値がないことを想像してみましょう。攻撃者は、ユーザーの1人である「Bob」を追いかけています。これは、「Bob」が銀行のサイトで使用しているのと同じパスワードをサイトで使用していることを知っているためです。彼はまた、ボブがそこに彼の命の節約を持っていることを知っています。さて、攻撃者が私たちのサイトのハッシュをクラックすることができれば、残りは簡単なものになります。

だからここに私の質問があります-追跡可能なパスなしでパスワードの長さをどのように延長しますか？または、ハッシュプロセスを複雑にして、タイムリーに複製する方法を教えてください。私が思いついた唯一のことは、ハッシュを数千回再ハッシュして、最終的なレインボーテーブルを作成するのにかかる時間を1,000倍に増やすことができるということです。これは、攻撃者がテーブルを作成するときに同じパスをたどる必要があるためです。

他のアイデアはありますか？

4

5 に答える 5

6

解決策として、ユーザー ソルトを使用してハッシュ入力をより複雑にし、50 文字以上にして、テーブルを生成できないようにします (そのサイズの文字列を大きくする方法)。さらに、ユーザーごとに新しいテーブルを作成する必要があります。問題: 彼らが db をダウンロードすると、ユーザーのソルトが取得されるため、彼らが十分に気にかけている場合は振り出しに戻ります。

この推論は誤りです。

レインボー テーブル (一般的な辞書攻撃の特定の実装) は、スペースを時間と交換します。ただし、ディクショナリ (レインボーまたはその他) の生成には多くの時間がかかります。複数のハッシュに対して使用できる場合にのみ価値があります。それを防ぐのが塩です。ソルトは秘密である必要はありません。指定されたパスワードに対して予測不可能である必要があるだけです。これにより、攻撃者がその特定のソルトに対して生成された辞書を持つ可能性は無視できるほど小さくなります。

于 2009-05-02T18:55:07.007 に答える
2

「私が思いついた唯一のことは、ハッシュを数千回再ハッシュし、最終的なレインボーテーブルを作成するのにかかる時間を 1,000 倍に増やすことができるということです。」

Blowfish ベースのBCryptハッシュとはまさにこのことではないでしょうか? ブルート フォース クラッキング (およびレインボー テーブルの作成) を元に戻すことができるように、ハッシュの計算にかかる時間を増やしますか?

「適応可能なコストを持つ2 つのアルゴリズムを提示します(...)」

適応可能なコスト ハッシュ アルゴリズムの詳細: http://www.usenix.org/events/usenix99/provos.html

于 2009-05-02T18:38:00.790 に答える
1

「コショウ」のアイデアを取り入れて、パスワードのハッシュ専用の別のサーバーに実装し、この1つのシンプルで可能な限り安全なサービスを除いてロックダウンします-おそらく、悪用を防ぐためのレート制限があります. 攻撃者は、このサーバーにアクセスするか、ペッパー、カスタム RNG、クリアテキスト拡張アルゴリズムをリバース エンジニアリングするかのいずれかで、克服する必要のあるもう 1 つのハードルを与えられます。

もちろん、彼らがすべてにアクセスできる場合、彼らはユーザーの活動をしばらく傍受することができます..

于 2009-05-02T18:42:43.867 に答える
1

うーん...さて、これについての私の見解：

  • ハッシュから元のパスワードを取り戻すことはできません。私はあなたのハッシュを持っています。そのハッシュに適合するパスワードを見つけるかもしれませんが、このパスワードを使用する他のサイトにはログインできません。いいえ、ここでは本当の問題はありません。
  • 誰かがあなたの DB やあなたのサイトを手に入れて設定を取得したとしても、とにかく失敗します。
  • 管理者またはその他のスーパー アカウントの場合は、2 つ目の検証手段を実装します。つまり、ログインを特定の IP 範囲に制限し、クライアント側の SSL 証明書を使用するなどです。
  • 通常のユーザーの場合、チャンスはあまりありません。パスワードで行うことはすべて、何らかの構成またはデータベースに保存する必要があるため、サイトがある場合は、魔法のスネークオイルも持っています.
  • 強力なパスワード制限が常に機能するとは限りません。一部のサイトでは、パスワードに数字を含める必要があります。その結果、ほとんどのユーザーは通常のパスワードに 1 を追加します。

ここで何を達成したいのか完全にはわかりませんか？ユーザーのパスワードの前にソルトを追加し、認証の 2 番目の手段で管理者アカウントを保護することが最善の方法のようです。

于 2009-05-02T18:51:45.577 に答える