パスワード推測ヒューリスティックの値を減らすためのクライアント側ハッシュ
はい、これは「さらに別のクライアント側ハッシュ」の質問です。しかし、まだ離れないでください、私はここにいくつかの価値があると思います。
パスワードハッシュデータベースが盗まれた場合のコミュニティ全体への影響を軽減するために何かしたいのですが。 （LinkedIn、Match.com、Yahooなどを参照してください...）
このような場合、漏洩したパスワードの統計分析を使用して、ユーザーのパスワードの解読を標的とするヒューリスティックを改善しました。私はそれが起こらないように手助けしたいと思います。
アイデアは次のとおりです。ユーザーのクリアテキストパスワードを取得し、クライアント側でできるだけ多くのラウンドをスローハッシュします。次に、サーバーに渡されるパスワードとしてハッシュを使用します。 password-client-hashを通常のパスワードと同じように扱い、サーバー側で再度スローハッシュします。
これにより、パスワードデータベースがヒューリスティック攻撃の影響を受けなくなります。 （まあ、実際には免疫がないわけではなく、ヒューリスティックを使用するには余分な費用がかかります。）
ただし、私の懸念は、クライアント側のハッシュ出力のエントロピーが減少すると、ヒューリスティックの価値を排除することで得た利益が排除される可能性があることです。
このトレードオフはどのように定量化できますか？アプローチについて何か考えはありますか？
編集
明確にするために、私はヒューリスティック攻撃の価値を下げようとしています。つまり、「Password1」を「tqwe657fdh」と同じくらい良いパスワードにしたいのです。つまり、攻撃者はどちらかをクラックするために同じスペースを検索する必要があります。
別の編集
議論は私が私の考えを明確にするのを助けました：
最近の非常に多くの大規模なパスワードデータベースのリークと、その結果としての一般的なパスワードとパターンの分析により、パスワードクラッキングシステムで使用されるヒューリスティックが改善されたに違いないと思います。
GPU支援ハッシュ実行の最近の進歩（ http://openwall.info/wiki/john/GP ）は、CPUの不均衡の利点を攻撃者にさらにシフトさせています。 （とにかく、それはすでにかなり不均衡でした。システムがインターネット規模に近づくと、集中型サーバーハードウェアで低速ハッシュパスワードを処理するのは難しい注文です。）
私は2つのことをしたい：
攻撃者がヒューリスティックから受けるメリットを排除し、真のブルートフォース攻撃を強制します。
パスワードデータベースが私から盗まれた後、クラッカーコミュニティに与えるメリットを減らします。
私のアイデアが役立つかもしれないと思いますが、トレードオフを定量化する方法が必要です。
標準のパスワード理論に基づくと、パスワードの生成方法がわかっていると想定する必要があるため、これは機能しないはずです。
私はあなたが求めているのはこれだと信じています、私が間違っているなら私を訂正してください。
標準的な方法の理解。
ユーザー1送信済み）password1->（保存済み）e38ad214943daad1d64c102faec29de4afe9da3d
---（ユーザー2送信済み）Di＃aKHn！@->（保存済み）9187b4dc0f7c7231334546a86984060233304c5e
保存されたハッシュに対する辞書攻撃は、正しく送信されたパスワードを回復しますか？
あなたがしたいのはこれです。
---（ユーザー1クライアント側）password1->（送信済み）e38ad214943daad1d64c102faec29de4afe9da3d->（保存済み）f8fde4f28c22e1a5a6201b6cce363477940cde50
---（ユーザー2-（クライアント側）Di＃aKHn！@->（送信済み）9187b4dc0f7c7231334546a86984060233304c5e->（保存済み）a893a40df9fc73ab3a9711a34e943f13271170c1
したがって、ユーザー1のパスワードはユーザー2のパスワードと同じくらい強力であるように見えます。これは、両方とも40文字の英数字の文字列をパスワードとして送信しており、ハッシュが辞書の単語ですが、長いハッシュです。
これが機能しない理由は、プロセスが人間側のエントロピーではなく、すべてプログラムロジックの一部であるためです。パスワードクラッキングは、SHA1（$ pass）やその他の制御（ソルトなど）ではなく、SHA1（SHA1（$ pass））になります。再現性の必要性を考えると、クライアント側でランダムな回数ハッシュすることはできないため、常に定義する必要があります。
あなたが提案していることを私が誤解した場合は、私に知らせてください。
編集：あなたが言っていると思うことをさらに拡張するために、以下のre：comments。
ハッシュにX時間かかるようにします。ここで、Xは、辞書攻撃を実行することが非現実的なポイントです。サーバーのリソースを考えると、bcryptのような遅いハッシュを使用すると、時間「Y」のスローダウンしか達成できないと言っていますが、これは「X」のしきい値を超えるには不十分です。クライアントCPUも「Z」を使用することを考えているので、辞書攻撃を役に立たなくするこの「X」しきい値を達成できるようになるまで、Y + Zが得られます。
私の答えは、クライアントとサーバーの間に十分なCPUパワーがあり、使用可能なサービスを維持しながら、誰かが辞書攻撃を試みるのにこれを非現実的にするのではないかと疑うことです。これは、GPU計算とCPU計算の差が非常に大きいためです。
結果のデータベースの場合、ハッシュが発生するかどうかclient-sideまたはserver-side実際には問題ではありません。攻撃者はハッシュを見て、パスワードを試します。
クライアント側のハッシュには、次の主な結果があります。
- CPUはサーバーではなく、クライアントに費やされます。サーバーは一度に100台のクライアントを管理する必要があるかもしれませんが、クライアントは一度に1台のサーバーにのみログオンするため、これは使用可能なCPUの効率的な使用法のように見えます。
- ただし、クライアントのCPUは、WebコンテキストではJavascriptを意味します。これは、JavascriptのオーバーヘッドのためにCPUの1％に似ています（JITコンパイルを使用しても、JavascriptはCPUを集中的に使用するタスクには適していません）。
- ハッシュにはsaltの知識が必要なため、プロトコルを変更する必要があります。クライアントはユーザー名を送信し、サーバーはソルトで応答し、その場合のみクライアントがハッシュを実行します。これは、特定のプロトコルに適用するのが簡単な場合とそうでない場合があります。追加の往復が必要です。
したがって、そのようにセキュリティが大幅に向上することはありません。クライアントにstorageを設定できると、状況が変わります。そうすれば、キー（何か秘密）をクライアントに保存し、 [〜＃〜] mac [〜＃ 〜] サーバーに送信される「パスワード」として（入力された）ユーザーパスワードを介して計算されます。サーバーをハッキングした攻撃者はデータベースを取得しましたが、クライアントに保存されているものは何も取得しなかったため、これにより、目的の「コミュニティサービス」がもたらされます。一方、クライアントのキーストレージには、独自の問題があります（特に、ユーザーはマシンを簡単に切り替えることができなくなります。キーは、何らかの方法でマシン間で転送する必要があります）。専用のストレージサーバーを使用して、これらのストレージの問題を解決できます。大体において、この解決策は KeePass モデルです。
サーバーやクライアントに特別なメリットはありません。事実上、クライアント側とサーバー側のハッシュ間のハンドオフポイントとして中間結果を使用しているように見えます。パフォーマンスを節約して、他の方法では法外なレベルのハッシュを利用できるようにしますが、最終的には、クライアントが中間ハッシュを有効な入力として返すため、攻撃者はサーバーのバージョンに対抗するだけで済みます。
「mypassword」でローカルにハッシュを1000回繰り返して、「jdqfr3bt」の値を取得するとします。次に、クライアントはそれをサーバーに提供する必要があり、サーバーはDBに一致する「91jf35j」を取得するために実行できる10回の反復を実行するため、それを許可します。
攻撃者として、DBから91jf35jを取得し、値「jdqfr3bt」がそれに一致することがわかるまで調べます。次に、実際に何もすることなく、クライアント側のハッシュの「結果」としてそれを提供します。サーバーはそれを有効と見なします。辞書から始めるのはコストがかかりますが、純粋なレインボーテーブルは影響を受けません。