安全な認証：クライアント側の部分的なキーストレッチ...私のアイデアをレビュー/批評してください
私はウェブサイトのための「完璧な」認証システムが何であるかを理解しようとしています。
一方では、単純なハッシュアルゴリズムが他の方法でブルートフォースまたはクラックされる可能性があることを知っています。したがって、MD5が推奨されなくなった理由。安全なパスワードストレージの最良の解決策は、ソルティングと組み合わせてキーストレッチングを使用することです（つまり、PBKDCF2、bcryptまたはscryptを使用）。それを聞いたことがない人にとって、キーストレッチはハッシュアルゴリズムが（一度だけではなく）何度も繰り返し計算されることを意味し、各ブルートフォースは計算に不当な時間をかけようとします。
ユーザーがサインアップ、認証、またはパスワードを変更し、サーバーがキーストレッチを使用してパスワードを保存するようにしても、適切なパスワード保護が保証されますが、DoS攻撃への扉は開いたままになります。主に、ハッカーはランダムなパスワードを使用した認証の試行でそれをあふれさせることができ、サーバーはそれらのすべての試行のすべての反復を計算するのを妨げます。
私は両方の世界のベストを手に入れようとしています-DoSドアを開かずに、キーを伸ばして安全なパスワードを保存します。ここに私の考えがあります。私が何かを監督しているかどうか、または私のロジックに問題があるかどうかを知りたいです...時々、あなたが問題に近すぎるとき...
アイデアは：
クライアント側：ウェブサイトのユーザーがユーザー名、パスワードを入力します
クライアント側：Webサイトは、サーバーへのAJAX要求を使用して、ユーザーのレコードに添付されたソルトと反復回数を取得します（ユーザー名の一致に基づく））
クライアント側：認証ステップ1. Webサイトは、クライアントのコンピューターでJavascriptを使用して、すべてのハッシュ反復MINUS ONEを計算します（理由は後で説明します）。計算は、PBKDF2、bcrypt、scryptなどのよく知られたアルゴリズムを使用して実行されます。ウェブサイトは結果をサーバーに送信します。
SERVER-SIDE：認証ステップ2.サーバーはユーザー名+ハッシュされたパスワードを受け取ります（マイナス1反復）。最後の反復を実行します（PBKDF2、bcryptまたはscryptを使用）。格納されている値と比較して、組み合わせが正しいかどうかを判断します。ウェブサイトへの応答を返します。
では、なぜすべての反復から1を引いたのでしょうか。ハッカーがデータベースのコピーを取得し、サーバーが完全にハッシュされたパスワードが提供されることを期待する場合、それはプレーンテキストでパスワードを保存することと同等です。ハッカーはハッシュをコピーして貼り付け、認証サービスを使用します。そのため、直接返品することはできません。
ただし、理論的にはハッシュを「リバース」することはできないため、サーバーがn-1反復ハッシュのみを受け入れるようにすることは、データベースでの表示に基づいて、ハッカーが前回の反復の様子を推測できないことを意味します。あれは正しいですか？
結局のところ、クライアント側で実行される作業の大部分（サーバーは1回の反復のみを実行）してDoS脅威を排除しますが、ソルトを使用したフルオンのキーストレッチで保存されたパスワードもあり、最も安全な方法です。
何か不足していますか？これは認証システムを実装する理想的な方法でしょうか？お知らせ下さい！ここに何か足りないのかな...
クライアント側のハッシュは概念的に機能します。ただし、問題はpowerの問題です。 Webのコンテキストでは、クライアントはJavascriptを使用します。Javascriptは、集中的なタスクを計算するのに弱いです。クライアントはすでに比較的小さなCPUのシステム（安価なスマートフォンなど）を使用していますが、Javascriptは独自のオーバーヘッドを追加します（これは解釈されるため、困難です [〜＃ 〜] jit [〜＃〜] 、適切な整数型がありません）。おおまかな見積もりとして、JavaScriptでのクライアント側のハッシュは、適切なサーバーでのパスワードハッシュよりも20〜40倍遅くなります。
残念ながら、ユーザーの忍耐力は伸びません。ユーザーは1秒または2秒の遅延を許容します。したがって、クライアント側のハッシュを使用する場合は、サーバー側のハッシュを使用する場合よりも反復回数を少なくする必要があるため、全体像が弱まります。
または、別の言い方をすると、毎秒20ユーザー以下のログインプロセスを処理する限り、サーバー側のハッシュでは、クライアント側のハッシュより多くの反復を使用できます。 、したがってセキュリティに優れています。
クライアントがJavaアプレットを使用する場合は、はるかに強力です。 「20x」係数は「3x」になります。しかし、Javaアプレットは時代遅れになり、タブレットやスマートフォンでは機能しません。専用のアプリを備えたモバイルクライアントは、クライアント側のパスワードハッシュ。
詳細については、最善の方法はアルゴリズムから「1回の反復を削除する」ことではなく、ハッシュを追加することです。暗号化アルゴリズムは複雑な動物です、およびパスワードハッシュ関数は内部的に「反復」を使用しますが、必ずしもonly反復を使用するわけではありません。たとえば、bcryptの「最後の反復」を簡単に削除して、部分的な結果をサーバーに送信することはできません。したがって、代わりに、クライアントですべての反復を行い、結果[〜＃〜] r [〜＃〜]をサーバーに送信します。サーバーは、saltとh（R）いくつかのハッシュ関数hの場合（例SHA-256）。
[〜＃〜] srp [〜＃〜] にはクライアント側のKDFがあるため、すでにクライアント側のキーストレッチが可能です。意欲がある場合は、サーバーのパフォーマンスに影響を与えることなく、ログインするたびにキーを引き伸ばしながら15分の書き込みサイクルを費やすことができます。
これは、その利点の多くの1つにすぎません。
私が見ることができる1つの欠陥は、クライアント側でn-1回の反復を行っているため、bcrypt/scrypt/PBKCDFを使用しても意味がないことです。これらのアルゴリズムの使用は、パスワードの解読に時間と計算を集中させるためです。現在のシナリオでは、攻撃者はn-1回の反復ハッシュをすぐに利用でき、さらにパスワードを推測するためにもう1回の反復のみを必要とします。これは、攻撃者にとっては簡単なことであり、私の知る限りでは、単純なデスクトップマシンで実行されます。
DoSを防ぐための1つの解決策は、誰か（悪意のあるユーザー）がアカウントにログインしたい場合、一定の試行回数の後、ユーザーが一定の時間ログインするのを停止し、この時間を指数関数的に増やし続けることです。たとえば、しきい値の試行を3とします。ユーザー名「user123」のユーザーがログインしている場合、（s）3つの間違ったパスワードを入力した後、5秒間アカウントをブロックできます。 5秒後にもう一度間違った試行があった場合は、アカウントを10秒間ブロックすることができます。
このようにして、1人のユーザーがリソースを独占し、ブルートフォース攻撃に時間がかかり、最終的には実行不可能にならないようにします。
編集：このアプローチのもう1つの問題は、クライアント側にソルトを送信していることです。 Saltは、パスワードの総当たりを困難にするために使用されます。現在のシナリオでは、攻撃者はユーザー名に対応するソルトも簡単に入手できます。
また、クライアントがJavaScriptを無効にすると、Webサイトにログインできなくなります。しかし、最近のWebサイトはJavaScriptに大きく依存しており、クライアントで有効にする必要があるため、これは大きな問題ではない可能性があります。
遅い鍵導出関数を使用して、次の2つの目標を達成したいとします。
攻撃者がログインできないようにする
クライアント側の反復ハッシュは、それ自体がパスワードの置換と見なすことができます。これはサーバーに送信され、もう一度ハッシュされて保存されます。攻撃者がこのパスワードの置き換えを見つけることができれば、ログインできます。事前反復ハッシュ（BCrypt）の出力は約60文字（7つの定数文字と21の既知のソルト文字）であるため、テストする1E50を超える組み合わせがあるため、ブルートフォースは実用的ではないようです。
攻撃者が元のパスワードを取得できないようにします。彼は他のWebサービスで使用できます
元のパスワードを見つけるために、攻撃者はすべての反復を行う必要があります。したがって、クライアント側で行われる反復は、辞書攻撃（頻繁に使用されるパスワードのテスト）を遅くします。
だから実際にはあなたの計画はうまくいくようです、少なくとも私は明らかな欠陥を見ることはできません。ただし、BCryptには1つの問題があります。このアルゴリズムは各反復で元のパスワードとソルトを使用するため、もう1回反復を実行できず、代わりにサーバーで追加のハッシュを計算する必要があります。
また、Thomas Porninの回答も読んでください。ハッシュサーバー側を実行するための実際的な理由があります（そして彼は専門家です）。