繰り返されるパスワードの推測を禁止することが当たり前にならないのはなぜですか？
誰もが、強力なパスワードの規則/必要性を認識しています。ユーザーがパスワードで使用できるさまざまな種類の手がかりの数に加えて、大文字と数字の置換のさまざまな順列を使用すると、ハッカーは、成功するパスワードを取得するために、平均して多くの試行を行う必要があります。
このリンク： 繰り返しのパスワード攻撃のスローダウン は、私が持っているのと同じ質問ではありませんが、すべての推測を阻止するためのいくつかの努力について説明します：繰り返しの推測を妨害するのが標準にならないのはなぜですか？誤った推測が行われるたびにバックオフ時間が長くなるのは1つの方法であり、他の方法についても議論されています。
Linuxシステムでのこのような推測や、Webベースの認証を阻止しようとする試みはほとんどありません。 3回間違えたとき、1つのシステムからロックアウトされました。
IT担当者は、文字数、文字、数字、大文字、パスワードからのユーザー名の除外など、ますます制約を課しています。しかし、それは単に数が実際に制限されていない状況で必要な試行の数を増やすだけです。
このが行われていないとの仮定に異議を申し立てたい。
[警告：ワイルドな近似に従う]
ブルートフォース攻撃が成功するためには、適切な時間（たとえば、パスワードの強度に応じて数時間から1か月）でクラックを実行するために、毎秒数百万または数十億回の推測が必要になることに注意してください。 1秒あたり100回のパスワード試行というレート制限でも、クラック時間は1か月から数十万年に増加します。多分私の基準は低いかもしれませんが、私にとってはそれで十分であり、合法的に自分のアカウントにアクセスしようとする人間のユーザーがそれに気付くことはありません。ある種のサービス拒否攻撃を防ぐために、レート制限がユーザー名ではなくIPによる場合はさらに優れています。
また、使用しているLinuxディストリビューションはわかりませんが、UbuntuおよびCentOSシステムでは、GUIまたは端末のログイン画面でパスワードを誤って入力すると、再入力する前に1秒間ロックされます。
サーバーがログイン試行を積極的にレート制限していない場合でも（実際にはそうする必要があります）、pingの時間だけで数百万年の速度まで遅くなります。おそらく10億回の推測/秒に到達する前にサーバーをDDOSするでしょう。本当のお金は、ハッシュされたパスワードデータベースのコピーを取得し、1秒あたり数十億回の推測が可能なGPUリグにフィードすることです。
TL; DR：ログインサーバーの強化に力を入れようとする場合、パスワードハッシュを改善し、レートを実装するよりデータベースを盗むのを難しくすることで、より多くの投資を得ることができます。 -ログイン画面での制限。
[〜＃〜] update [〜＃〜]：これは口コミで広まったため、コメントから何かを取り込みます。
このロジックは、ログインサーバーにのみ適用されます。電話やラップトップなどの物理デバイスの場合、「3回試行してロックする」または「10回試行してデバイスをワイプする」タイプのことは、パスワードを入力しているときに誰かが肩をたたくか、または汚れパターンを確認できるため、理にかなっています画面上で、または4桁のPINとにかく10,000の組み合わせしかないため、必要な推測の数は非常に多いことを知っています ずっと小さい。
無効な試行を繰り返した後に人を締め出すことには、重大な問題が1つあります。これは、実際には一種のサービス拒否攻撃の攻撃ベクトルになります。数十万のアカウントすべてがサービスを妨害しようとする誰かによって一貫してロックされてしまう場合、サポートデスクまたはカスタマーサービスサイトに何が起こるかを考えてください。
私が使用しているWebサイトでも、パスワードを変更するたびに物理的なメールを送信しています。特に嫌な人は、アカウントのリストを見つけてそれらを繰り返し停止することで問題を引き起こす可能性があります。
セキュリティと使いやすさの間には間違いなく判断の呼びかけがあり、私は個人的には決まった答えやパットな答えがあるとは信じていません。
十分に複雑であるため、ブルートフォースを行うことは技術的に非現実的であり、速度を落としてもそれほど効果はありません。
「しかし、それは単に必要な試みの数を増やす」というのは、何十億年も長く言われると、奇妙な方法です。
ログインを使用してのみパスワードをチェックできると想定します。しかし、多くの場合、誰かがパスワードのハッシュテーブルを取得できるようにするデータ漏洩/ハッキングがあります。それらを持っている場合、彼はハッシュをブルートフォースすることができます。これはログインを使用するより数倍速いです。そして、ここで本当に良いパスワードが必要になります。
これまで他の回答で言及されていなかった非常に重要な概念は、オフラインとオンラインの総当たりの違いです。
オフラインのブルートフォースでは、攻撃者はハッシュ化されたパスワードにアクセスでき、ここでの主な防御策は適切なパスワードハッシュアルゴリズム（bcryptなど）を使用することです。ハッシュアルゴリズム、GPUクラッキングなどのポイントは、オフラインのブルートフォースにのみ関連しています
この質問は、攻撃者がシステムにリモートでログインしようとしているオンライン総当たり攻撃に関連していると想定しています。
前述のように、SSHなどのサービスのリモートログインでは、リモートパスワードの推測は、fail2banなどによって一般的に禁止されています。
それが一般的ではないのは、Webアプリケーションです（この機能がないために、Webアプリケーションの所有者に調査結果を提供するのはかなり一般的だからです）。
一部のシステムではストレートロックアウトが設定されていますが、これは、攻撃者のパスワード推測攻撃によるサービス拒否のリスクと、アカウントを再アクティブ化するメカニズムによってはユーザーの不便のリスクに直面しています。
より良い解決策は、ログイン試行の遅延を強め、攻撃の実行可能性を低下させることですが、場合によっては、攻撃者が1つのアカウントを侵害するだけでよいことに注意することが重要です。誰かがそれらを使用することを期待して、ユーザーベース全体で少数の一般的なパスワードを試すことができます。
これを簡単に見る方法は、別の質問です。 SHA-1/MD5に既知の欠陥/問題があるのになぜそれがまだ使用されているのですか？
簡単に言えば、個人/企業のリスク評価では、これらの問題は大きな問題ではないと見なされています。ローリングタイムアウトの場合と同じです。
私が地元の学校の管理を行ったとき、教師が自分のパスワードを「推測」することは非常に一般的でした。教師に待たせるのははるかに不便でした。4〜5個の間違ったパスワードの後でアカウントをロックアウトし、ロックを解除するように私に電話してもらいました。
ローリングタイムアウトも対処すべき大きな問題です。ローカルシステムの場合、これは問題ではないかもしれませんが、私の学校の例（上記と同じ）、または1,000人を超える従業員を抱える大企業を例にとります。誰かがパスワードプロンプトに座って、正しいパスワードを入力する機会を待っているため、作業を実行できなくなりました。おそらく誰かがプロンプトに数時間座ってもらうのはおかしいと思ったのでしょうか、それとも攻撃者が本番を遅くしたいと思ったのでしょうか？タイムアウトの長さを管理する方法、増加する量、およびリセットする方法が必要であることを考慮してください。
Windowsで許可されているようなロックアウトシステムは、実際にはより安全であると私は主張します。これには管理者の介入が必要であり、元に戻すのがはるかに速くなります（さらに、ログの確認にかかる時間も）。 Webベースのシステムでは、ローリングタイムアウトの方が効果的ですが、すでに見てきたように、パスワードハッシュがリークされ、ローリングタイムアウトは役に立ちません。