間違ったパスワード-再試行回数-許可するのに適した番号は何ですか？
ほとんどのサイトとソフトウェアでは、3回の試行を誤ると、デフォルトで自動ロックまたは時間ロックが設定されているようです。
私はその数はもっと多くなる可能性があると感じています-再試行を許可しないのは主に自動化された総当たり攻撃を防ぐためです。ブルートフォース攻撃が4回の再試行でパスワードを正しく取得する可能性は、3回の再試行でパスワードを取得するのとほぼ同じです。つまり、非常に小さいです。セキュリティを損なうことなく、これをはるかに高く保つことができると思います。
再試行のたびに再試行する時間を増やすなど、他の戦略があることは知っていますが、「n」回試行した後にロックするなどの単純な戦略について質問しています-適切な最大「n」はいくつですか？
ログインフォーム自体へのアクセスを制限する別の手段がない限り、適切なベースラインはハードリミットがないです。これは、誰かがアカウントから完全にロックアウトされるのは簡単すぎるためです。
これは明らかにサービス拒否のせいで悪いことですが、それ自体がセキュリティの問題でもあります。アカウントのロック解除を求める人々からのサポートリクエストが増加し、ロック解除を行う人々は慣れ親しむようになり、「ねえ、私のアカウントはロックされています」で始まるソーシャルエンジニアリング攻撃がはるかに容易になります。
代わりに、タイムアウトを延長します—ただし、無限ではありません。パスワードの複雑さの要件を前提として、推測の数を時間の経過とともに妥当な量に制限するのに十分です。
私の意見では、これは一般的に答えることはできません。それは、ユーザビリティ、セキュリティ、およびその他のパラメータに関する要件によって異なります。
主な要因の1つは、特定のシナリオで考えられるパスワードの範囲がどれほど大きいかです。攻撃者がパスワードに関する詳細情報を持たず、特定のパスワード権限を推測するために、可能なパスワードの組み合わせの数に対して1の確率で適切な組み合わせをブルートフォースする必要があると仮定します。
たとえば、4桁の場合PIN数値可能な組み合わせは10,000あります（10 ^ 4）。1回の試行で特定の組み合わせを推測する可能性は1〜10,000または0.01％です。2回の試行を2倍にすることができます0.02％までそれを推測するチャンス。
特定のシナリオに適切なトレードオフを見つけるのはあなた次第です。 ただし、ブルートフォースは検討する必要がある唯一の攻撃方法ではないことに注意してください。一部の攻撃者はターゲットに関する追加情報を持っている可能性があるため、より可能性の高い組み合わせを試すことで、推測の可能性を向上させることができます （たとえば、標的となる人物がパスワード内で個人情報を使用し、攻撃者がそれを知っている場合）。
問題
最初の注意：私はWebサーバーに偏っていますが、ここで述べられていることの多くは他の種類のサービスにも当てはまります。
問題はサービス拒否です。これは2つの方法で発生する可能性があります。1）攻撃者がブルートフォースを実行してサーバーが飽和状態になり、だれもサービスにアクセスできなくなります。 2）ユーザー（悪意のあるなしにかかわらず）が何度も試行し、アクセスがロックされる可能性があります。
その他の考慮事項
エラーがユーザー名またはパスワードのどちらにあるかをユーザーに知らせることにより、攻撃者はブルートフォース/辞書のユーザー名を使用できるようになります。これはユーザビリティに反しますが、アカウントがデフォルトで非公開または匿名を意図している場合は、セキュリティの側面を選択する必要があります※。
アカウントがロックされていることをユーザーに伝えると、攻撃者が多くのアカウントをロックすることで問題を引き起こしやすくなります（これはサービス拒否の一種であり、多くのサポートチケットにつながる可能性があります）。また、存在しないアカウントはロックできないため、攻撃者はこの方法でアカウントを発見できます。偽のアカウントのロックを模倣することを検討してください。
アカウントの発見は、総当たり攻撃や辞書攻撃の半分であるだけでなく、将来のソーシャルエンジニアリングにも役立ちます。
ブルートフォース/辞書攻撃の変種は、多数のユーザー名に対して同じパスワード（通常は統計的に一般的なもの）を試すことです。
※：検索エンジンはユーザー名をインデックス化できますか？もしそうなら、使いやすさを選択します（攻撃者はとにかく検索エンジンのキャッシュに有効なユーザー名のリストを持っています）。アカウントを持っている人を知ることが機密情報と見なされる可能性があるサイトでは、検索エンジンがそのような情報にアクセスすることを許可しないでください。
可能な解決策
問題を解決しようとするいくつかの一般的な事柄があります：
- CAPTCHAを追加
- 再試行時間を追加する
- アカウントをロックする
- 原点をロックする
- 二要素認証
ファイアウォールレベルまたはWebサーバー構成レベルでのみIPをロックすると、サーバーの負荷に実際に影響することに注意してください。ただし、指定されたアカウントとペアになっているときにOriginのみをロックする場合、ロジックはサーバー側のコードになります。残りのソリューションについても、サーバー側のコードが必要であることは事実です。
これらのソリューションはサーバー側のコードに依存しているため、サーバーをフラッド攻撃から実際に保護することはできません。 これは、これらのメソッドの主な用途が抑止力であることを意味します。
単語：
この投稿のコンテキストでは、これらの単語はここで言及されている意味を持っています：
"ロック"： "追加の認証が提供されるまでアクセスを禁止する"、同じではないにしても、パスワードを忘れたユーザーに提供される手順と同様の手順に従う追加の認証手段を提供します。
「Origin」：サーバーが接続のソースを識別するために使用するIP、ユーザーエージェント、またはその他の手法。使用する場合は、サーバーがそのような情報を記録することをプライバシーポリシーに記載する必要があります。
「サードチャネル」：メール、SMS、専用アプリ、またはサーバーの制御外にあるその他のプライベート通信媒体。
この定義では、ユーザーからの追加の認証は必要なく、代わりに待機するため、再試行時間はロックではないことにも注意してください。
そして、十分な回数とは言えないため、パスワードをハッシュ化してソルト化します。
CAPTCHA
すべてのCAPTCHAソリューションが視覚的であるとは限らないことに注意してください。聴覚的なものもあれば、テキストによるものもあります（例：「リストの紫、ペンギン、青、白、赤の色はいくつですか？」）。
長所
CAPTCHAは、サードパーティのソリューションを使用して簡単に実装できます。サードパーティのソリューションを使用すると、問題を外部化して、CAPTCHAを十分に強力にすることもできます。
短所
CAPTCHAを使用すると、パスワードの入力に問題がある正規のユーザーにとっては不便になる場合があります。現在のreCAPTCHAでは、行動分析を使用して人間のユーザーを特定することで、この問題を軽減しています。
ロボットは、巧妙なAIによって、または単に攻撃者にそれを解決するように依頼することによって、CAPTCHAを解決できます。
再試行時間
長所
再試行時間には、時間を稼ぐという利点があります。したがって、これを3番目のチャネルの通知と組み合わせて、アカウントの所有者に警告することができます。
ユーザーはどのようなアクションをとることができますか？より強力なパスワードを使用することを提案できますが、それでも実際には問題が解決されません。
別の方法として、攻撃者のマシンからのアクセスを拒否するオプション（つまり、Originとアカウントの組み合わせをロックする）をユーザーに与えることを検討してください*。 「原点のロック」を参照してください。
※：認証が必要で、現在のアカウントにのみ影響します。アカウントが別のアカウントをロックすることにつながる可能性のある欠陥を回避するように注意する必要があります。
短所
再試行時間を使用すると、パスワードの入力で問題が発生する可能性がある正当なユーザーにとって不便になるため、サービスの使いやすさが低下します。これは、認知的ダウンタイムであるため、CAPTCHAよりも最悪です。
攻撃者が1時間に1回程度攻撃を試みた場合でも、総当たり攻撃/辞書攻撃は実行可能です。この問題に対処するための代替策には、パスワードを頻繁に変更するセキュリティポリシー（ユーザーが同様のパスワードを選択すると効果がなくなる可能性があります）、および攻撃者を検出するためのIDSまたはその他の分析（複数のソースからの攻撃を分散させることで回避できる可能性があります）それ自体が抑止力になるほど高価です）。
アカウントをロックする
長所
時間の経過や複数の発生源に対する攻撃の拡散に対する耐性があります。
短所
アカウントをロックすると、試行の失敗回数が多いため、正当なユーザーがアカウントからロックアウトされる可能性があります。
また、3番目の場所での攻撃者による試行の失敗は、正当なユーザーをロックアウトします。 Originのロックとアカウントのロックを組み合わせると、より詳細な制御が可能になります。この場合、アカウントは、アクセスが試行されているオリジンに対してのみロックされます。
攻撃は、ロックアウトされた正当なユーザーがサポートに連絡したり、代替サービスを見つけたりすることにより、システムに影響を与える可能性があります。
原点をロックする
長所
アカウントとは関係なくオリジンをロックすると、アカウントを罰する代わりに攻撃者を阻止できるという利点があります。
短所
では、サーバーが要求の発信元を追跡し、失敗した試行と成功した試行を区別する必要があります。
攻撃の発信元は多くのユーザー間で共有される可能性があり（インターネットカフェなど）、発信元をロックすると正当なユーザーがロックアウトされる場合があります。
Originのロックとアカウントのロックを組み合わせると、より詳細な制御が可能になります。この場合、最初に、Originはアクセスしようとしているアカウントに対してのみロックされますが、多くのアカウントに対してロックされているOriginはグローバルにロックできます。
二要素認証
2要素認証のすべてのバリアントは強力な総当たり/辞書抑止です。主に2つのバリアントがあります。
認証を許可するために、3番目のチャネルを介してコードを送信します。それは、そのコードのブルートフォースを防ぐための追加の手段を必要とするべきではありません。
認証には専用のハードウェア/ソフトウェアキーのコードが必要です。キーは、認証を許可する使い捨てコードを提供する必要があります。
長所
2要素認証は、ブルートフォース/辞書攻撃を実際に無効にできる唯一のソリューションです。これは、1回限りのコードを要求することで実現されます。1回限りのコードは、複数回試行しても推測されません。
短所
2要素認証は多くの場合、実装にコストがかかります。
何を使う？
ブルートフォース/辞書攻撃を阻止するために追加の保護を追加することは理にかなっています。これらの対策の必要性は、パスワードスペースが小さすぎるシステム*、またはパスワードの最小強度が低すぎる場合（たとえば、銀行で一般的な4桁のピン）に増加します。
※：パスワードのサイズにアッパーキャップを付けると良いです。このようにして、パスワードに高価なハッシュを作成しているときにサーバーが妨害されることはありません。そして、それはbure force攻撃盗まれたハッシュコードに対してを阻止するので、高価なハッシュを使用するべきです。
CAPTCHAは、（reCAPTCHAなどの安定したソリューションを使用して）実装が非常に簡単で安価であるため、最初のオプションにする必要があります。
再試行時間とロックの間で、実行可能な最小限の実装が類似していることを考慮してください。アカウントをロックするには、フィールドをアカウントオブジェクト/レコードに追加し、それをロック済みとしてマークし、認証時にチェックして...再試行時間を設定します。保存するのは、認証が再度有効になる時刻である点を除いて、同じことを行います。
数回の試行が失敗した場合にこれらの手段を追加することにより、不便を軽減することは理にかなっています。その場合は、CAPTCHAを最初に適用します。これは、ユーザーの認知的ダウンタイムを引き起こさないためです。
ロックオプションの間で、Originとアカウントを組み合わせる方が、どちらか一方を単独で行うよりも優れている（ただし、より複雑でもある）ことがわかりました。実装にはログと分析が必要です。
最後に、2要素認証には、上記のソリューションを超える利点があります。しかし、サードパーティのサービス（メールサーバー、SMSサービス、専用アプリ、専用ハードウェアなど）への接続を必要とするため、実装するのが最も高価です。
ロギングと分析を実装することをお勧めします。それらに基づいて、ロックを実装するか、2要素認証を実装するかを決定します。
何回試行？
あるだろう：
- ん1 catpchaが現れるまで試みます。
- ん2 再試行時間が表示されるまで試行します。
- ん３ ロックが適用されるまで試行します。
注：2要素認証を使用する場合は、最初の試行から使用します。
この変数の値は、分析に基づいて将来調整することができます。ただし、妥当なデフォルトについては、以下を考慮してください。
ん1 パスワードの入力に問題がある場合に、ユーザーが実行できる試行回数の推定です。 2回の試行が最小になります1 これは、基本的なキャップエラーの原因です。注：CAPTCHAを使用する前に、Gmailでは20回試行できます。
ん2 回復メカニズムにアクセスする前に、人が行う試行の推定数である必要があります。ハードミニムはありません。実際には、CAPTCHAを適用し、待機する時間間隔が増えるとすぐに適用できます。私の意見では、n2 = 3 * n1 良い出発点です。
ん３ 攻撃が行われている可能性が高い試行回数の推定値である必要があります。 CATPCHAと再試行時間は手動による攻撃を阻止する必要があるため、n３ より高くする必要はありません。私の意見では、n３ = 2 * n2 良い出発点です。
再試行時間に関する注意：ユーザーが待機する必要がある間隔は、試行ごとに長くすることができます。これにより、非常に短い初期間隔（たとえば1秒）を使用して、そこからハードキャップ（たとえば1日）まで蓄積することができます。
試行回数のカウントに関する注意：試行回数のオーバーフローを回避する必要があります。試行回数をアカウントオブジェクト/レコードに保存する場合は、オーバーフローを処理します。ログでクエリを実行して、最後に成功した試行から失敗した試行の数を取得する場合は、時間間隔を追加することを検討してください（クエリ時間にも上限があります）。
リスクはデータの値、許可および適用される複雑さのレベル、最小/最大パスワード長、および場合によっては実装した他のセキュリティ対策に基づいているため、「安全」と見なされる数値はかなり恣意的です。
典型的な数は3から10の間です。失敗した試行の間に増加するタイムスパンを実装する場合、比較的長いパスワードの長さと複雑さを許可/奨励または強制する場合にのみ、より高い方に進むことができます。
覚えておくべきことは、ほとんどの人がランダムなパスワードを思い付かないということです。たとえば英国では、最も一般的なピンは1966で、もう1つの一般的なピンは1066です。どちらも歴史上有名です。もちろん、Wordの中から選択できるものは他にもありますが、人々は依然として一般的な単語で終わることがよくあります。したがって、特にシステムがタイムアウト後にさらに試行を許可する場合は、短いパスワードで4回の推測を許可する方が、思ったよりも効果的です。
もちろん、多くのサイトでは、リスクとデータの機密性が低い場合、これはそれほど重要ではありません。
タイムアウトを延長することに加えて、セキュリティを向上させる別の良い方法は、数回の試行が失敗した後に認証の第2要素を要求することです。多くの場合、電子メールまたは電話にコードを送信します。
また、さまざまなネットワークから、特にさまざまな地域からのログイン試行を防ぐこともできます。失敗したログイン試行をログに記録して監査することもお勧めします。
これらの戦略は、リスクを最小限に抑えながら、高レベルのカスタマーサポートコールを回避するのに役立ちます。
私が一般的に使用するのは、X in Yの時間式です。 1秒あたり3回の試行はロックアウトですが、60秒以内に3回試行しても問題ありません。 60秒で60回試行するのはよくありませんが、1日60回試行しても問題ありません。
多くはあなたが何を保護しようとしているかに依存します。また、会社のポリシー、HIPAAなどのように、従う必要のある外部ルールがある場合。
一般的な考え方は、「悪者」がただあきらめて先に進むのに十分な時間がかかるプロセスでなければならないということです。そうは言っても、ログインの試行を結び付けるのではなく、IPとIPの範囲にも関連付けることが重要です。
また、多くのことは「復元アクセス」プロセスに依存します。顧客が配送状況を取得できるAPIを実行するとします。ロックアウトされている場合は、サポートに連絡して確認する必要があります。この場合、2分ごとに120回の試行や、24時間で400回の試行などを許可します。それは高いように思えるかもしれませんが、「復元」ポリシーでは、スクリプトの1つがうまくいかない場合、顧客のビジネスは数時間または数日間ダウンする可能性があります。
一般的な考え方は、ブルートフォース攻撃を停止または延長することですが、通常のユーザーが不正な資格情報を使用している場合でも、通常のユーザーの邪魔をしないことです。