1秒あたり100回の試行に基づくWebサーバーの最小パスワードセキュリティ
この洞察に満ちた記事は、パスワードが非常に安全である必要はないことを提案しています： http://www.baekdal.com/tips/password-security-usability ？
ここには、私が困っている特定の行が1つあります。
実際の数はさまざまですが、ほとんどのWebアプリケーションは、1秒あたり100を超えるサインイン要求を処理できません。
ほとんどのWebアプリケーションは、1秒あたり100回の試行から保護する必要があるだけでよいというのは本当ですか？複数の侵入者によって攻撃される可能性のある分散システムを扱う場合、非常に少ない数のように思われます。
[〜＃〜] edit [〜＃〜]私の質問の詳細：ほとんどのWebサーバーの現在の平均パフォーマンスに基づいて、最大値はいくつですかブルートフォース攻撃中に可能なログイン試行回数は？私は、誰かが実際にログインの試みをクランクアウトできるオフラインパスワード攻撃については尋ねていません。
見通しを立てると、（ハッカーがログイン試行を通じてDoSを実行するのを防ぐために）タールピッチングまたは一時的なアカウントの無効化を使用できないシステム、つまりWebベースのシステムでの1秒あたりの実際のログイン試行回数が必要であるとします。とても便利です。
ただし、ほとんどのWebアプリケーションは、1秒あたり100を超えるサインイン要求を処理できません。
これは次のことを意味します：その記事の著者は、1秒あたり100を超えるサインインを送信することは、「ほとんどの"Webアプリケーション。
通常のWebアプリでは、サインインごとにパスワードをハッシュし、データベース内のハッシュされた表現と比較する必要があります。 webappが 優れたハッシュ関数 を使用している場合、これは確かにかなりの量のCPUを使用します。したがって、この主張はおそらく完全に不合理ではありませんが、私の経験では、ほとんどのWebアプリは、CPUを集中的に使用しないMD5、SHA1、SHA256などの単純なハッシュを使用しています。
その記事の大きな誤りはここにあります：
注：以下の例は、1秒あたり100回のパスワード要求に基づいています。
次の段落では、作成者は1秒あたり100回の最大攻撃率に基づいて、パスワードの強度について提案します。これは、攻撃者がライブWebアプリケーションに接続するonline攻撃の妥当な数である可能性があります。
しかし、攻撃者が最初にfxを介してデータベース全体をダウンロードしたonoffset攻撃の場合、SQLインジェクション攻撃は完全に間違っています。たとえば、これは SHA1のNVIDIA CUDA実装 で、小さなサーバークラスターで毎秒4700万ハッシュを実行できます。
webアプリケーションは、1秒あたり100回の試行から保護できる必要があるだけですか？
申し訳ありませんが、いいえ、あなたはこの部分を誤解しています。今、あなたは保護しようとしているwebapp所有者の観点からそれを見ています。onlineブルートフォースパスワード推測攻撃に対して。これに関しては、アクションlongを実行する必要があります。
- 個々のアカウントで一定数のログイン試行が失敗した場合（3、5、10、25はすべて妥当な数である可能性があります）、アカウントを一時的に無効にする必要があります。 （または、さらに良いことに、アカウントを無効にしないで、ログインの試行を遅くします。つまり、ターピッティング/レート制限です。）
- システム全体で1秒あたり数百回のログイン試行の失敗が発生している場合は、ログ/監視フレームワーク（Nagiosなど）がアラートを叫んでいるはずです。これにより、攻撃に気付くことができます。
最後に、記事に付随するFAQ を読むと、著者の意味がより明確になります。彼は、サーバー側でのパスワードの処理についてではなく、エンドユーザーが適度に安全で覚えやすいパスワードを生成する方法について話している。
質問編集後の更新：
ほとんどのWebサーバーの現在の平均パフォーマンスに基づいて、ブルートフォース攻撃中に可能なログイン試行の最大数はいくつですか？
SHA1のような単純なハッシュの場合、単一のクアッドコアサーバーは、優れたプログラミング手法を前提として、1秒あたり10,000リクエストという非常に大まかな球場で処理できると言えます。 HTTP接続処理のオーバーヘッドがSHA1の計算速度を支配するため、使用するwebappフレームワークとプログラミングに完全に依存します。 fx PHPを使用してPreforkモードでApacheを使用している場合、その数は非常に多く、サーバーあたり1秒あたり2,000リクエストになる可能性があります。
タールピッチングや一時的なアカウントの無効化を使用できないシステムが必要だとします。
次に、要件を変更します。これは修復できないほど壊れています。
webベースのシステムでの1秒あたりの実際のログイン試行回数は非常に便利です。
繰り返しになりますが、ブルートフォース攻撃longがこれほど大規模になる前に、警告を発する必要があります。
あなたはブルートフォーサーのために簡単な刑務所を実装することができます。ログインに3回失敗した後、そのIPからのログインを1分（またはそれ以上）ブロックしますが、クライアントユーザー/パスワードの不一致に送信し続けると言います
別の方法は、ユーザーと管理者のログインを分離することです。たとえば、ユーザーログイン用のメインフォームを作成し、その近くに管理者ログイン用の偽のボタンを配置すると、魔女は常に「パスワードが正しくありません」と表示されます。実際の管理者ログイン用に非表示のWebページを作成します：D
「ほとんどの」Webアプリケーションについてどのように答えればよいでしょうか。そもそも、ほとんどはおそらく会社のイントラネット上にありますが、2台以上のサーバーで実行されているWebアプリにアクセスするまでには、おそらく「ほとんど」が不足しています。
とにかく、1秒あたり100リクエストしか受け取れないとは思わないので、防御する必要があるのはそれだけです。これが質問の響きですが、おそらく1秒あたり100リクエスト（60,000 /）しか処理できないと思います。分）そのレベルは良いトレードオフになります。
アプリが1秒あたり1000回のログインを処理できる場合は、考え直してください。
この記事では、ログイン応答を遅くしてブルートフォース攻撃が不可能になるタールピッチングについては触れていません。5回ログインしようとすると、パスワードを入力するたびにそこに表示されます。失敗したと言う前に何年もの間かき回し、10回試行すると遅延が大きくなります。試してみると速度が低下し続けますが、20分後に離れて戻ってくると、再び速くなります。
これを行うと、ブルートフォースがほぼ不可能になる可能性があります。
その記事の著者は、「通常の」Webアプリケーションが処理できる要求の数について大きな仮定を立てています。サイトが適切に記述されたコードを備えた専用サーバー上にある場合、汗をかくことなく1秒あたり1,000件のリクエストを処理できる可能性があります。最適化されていない古いサーバーは、Grindが停止するまで、1秒あたり10リクエストしか処理できない場合があります。著者は計算の基礎となる数値を選択する必要があり、100から始めるのが妥当なようです。
ブルートフォース攻撃や辞書攻撃から防御しようとしている場合は、TessellatingHecklerが述べたように、タールピッチングや、記事で提案されているようにアカウントに一時的なロックをかけるなど、さまざまな手法を使用できます。特定のレートを超えるリクエストの送信を確認したIPからのリクエストを単に無視するシステムを見たこともあります。
元の質問に関しては、攻撃者はサーバーを停止せずにできるだけ多くのパスワードを試すことができるようにしたいので、1秒あたりの特定の数の要求に対して「防御」できる必要はありません。攻撃者は、自分自身に注意を向けないことが最善の利益であるため、サーバーで速度低下を引き起こすことがわかった場合、自分のツールをレート制限します。予想される通常の負荷に加えて、成長とトラフィックの時折の急増に対するある程度のマージンを処理できるようにアプリケーションを設計するだけです。
一般的なDDoS攻撃が心配な場合、それはまったく別の問題であり、パスワードの試行に対する1秒あたりのリクエスト数とは関係ありません。