残りのパスワード再試行回数の表示はセキュリティリスクですか？
一部のWebサイトでは、間違ったパスワードを2回以上入力すると、残りのパスワード再試行回数が表示されます。たとえば、アカウントをロックアウトするまで、3回の再試行があることを表示します。これはセキュリティの観点から危険ですか？
そもそもアカウントのロックはお勧めできません。不正なユーザーを排除することで、組織のセキュリティを強化しているように見えるかもしれません総当たり攻撃を使用してパスワードを「推測」しますが、実際に何を解決しましたか？このポリシーと、セキュリティ上のミスを犯さない完璧なユーザーベースの場合でも、攻撃者はパスワード「aaa」を繰り返し使用して重要なユーザーのアカウントをロックアウトすることにより、組織に対してサービス拒否攻撃を実行できます。攻撃者がIT部門全体のユーザー名のリストのコピーを取得した場合にどうなるかを考えてください。突然、IT自体（他のユーザーのロックを解除できる組織）が完全にシャットダウンされます。
ポリシーを実装する前に、常に脅威モデルを検討してください。組織を傷つけると決定した「悪者」は、代替の攻撃ベクトルを見つけます。ロックアウトポリシーは、国家国家の俳優（ロシア、中国、NSAなど）を混乱させることさえありません。断固としたハッカーはそれを回避する他の方法（ソーシャルエンジニアリングなど）を見つけるだけです。ロックアウトカウンターの設定がいくら低くても高くても、サービスの正当なユーザーにのみ害を及ぼします。
ストーリーのモラル：アカウントをロックアウトしないでください。代わりに、Appleが行うことを実行してください。ログインするたびに、ログインの遅延が2倍になります。 、そのため、12回程度の失敗の後、次の試行のたびに1時間待つ必要があります。これは、「悪意のある人」がブルートフォース攻撃を実行するのを防ぐのに十分な長さですが、正当なユーザーがその時間を費やすのに十分なほど短い時間です。パスワードが何であるかを調べて、昼食後に適切に入力するか、ITに連絡して謝罪の助けを求めます（同様に、「フラッディング」ポリシーは、ユーザーアカウントだけでなく、ファイアウォールのIPアドレスレベルで実装することができます。専用の攻撃者が多くの異なるアカウントをブルートフォースで攻撃しようとしていることを懸念している場合は、ソフトウェアのレベル。
また、アカウントをロックアウトしない場合は、カウンターを持つ必要はありません—または表示するカウンター。
[も参照： 同様の質問に対するこの優れた回答]
それはあなたのロックアウトメカニズムに依存します。しばらくして無効なログインがリセットされ、ロックされたアカウントがロック解除されない場合、カウンターを表示することで、攻撃者がアカウントをロックアウトしないようにすることができます。しかし、熟練した攻撃者は事前にロックアウトポリシーを決定しており、パスワードを推測するときにこれを考慮に入れます。したがって、影響は限られています。
また、ログインメカニズムを保護するためにこれに依存することには要点がありません。適切なパスワードポリシーとロックアウトポリシーを一致させる必要があります。パスワードポリシーが強力である場合、攻撃者はそれを正しくする前に何度も推測する必要があります。 20回の試行後にアカウントをロックした場合、侵害される可能性はほとんどありません。
あなた自身に問いかける必要があります：この情報を正規のユーザーに示すことの利点は何ですか？多くの場合、このロックアウトの問題は、試行回数の設定が低すぎるために発生します。 3または5が一般的な選択です。 NIST（現在、政府の閉鎖により現在利用できないため、直接の参照はまだありません） 100回未満の試行を推奨 。
NISTには、攻撃者が3回の試行では推測できないが、100回の試行では推測できるパスワードを考えてください。すべての攻撃者は異なる辞書とアプローチを使用します。パスワードが100回の推測に耐えるのに安全でない場合は、より少ない試行回数でパスワードを侵害することもできます-可能性は低くなります。したがって、適切なパスワードポリシーは必須です。
サイトが復旧したら、NISTリファレンスを追加します。 トロイハント にはいくつかの 良いブログ投稿 があり、パスワードとログインのメカニズムを要約しています。彼はNISTガイドラインのファンでもあります。
原則として、それはセキュリティリスクであってはなりません。もしそうなら、あなたはあいまいさ（隠された情報）を通じてセキュリティに依存しているでしょう。
カウントを非表示にすることは、せいぜい、敵対者にとってささいな不便になるでしょう。
対照的に、カウントを非表示にすると、正当なユーザーにとって非常に不便になります。入力を間違えたと想定して、間違ったパスワードを入力し、それを数回再入力することも珍しくありません。別の不正な試みでロックアウトされることがわかっている場合は、パスワードを調べて、コピー/貼り付けするか、慎重に入力します。ただし、無意識のうちに自分のアカウントをロックアウトすると、ロックを解除するために多くの追加のトラブルを経験する必要があります。
これについて別の見方をすると：熟練した攻撃者には関係ありません。
今日、オンラインアカウントはどのように侵害されていますか通常1？一般的に使用される1つの手法には2つのバリエーションがあります。
パスワードハッシュ（またはプレーンテキストのパスワード）を持つデータベースは盗まれ、攻撃者によってオフラインでクラックされます。ハッシュのクラックに成功すると、最初の試行で正しいパスワードがログインメカニズムに提供されるため、この制御は無効になります。
これは、問題のサービスのデータベースまたは別のサービスのデータベースのいずれかです。残念なことに、人々はいくつかのサービスでパスワードを再利用する傾向があるため、可能性が高く、いったんパスワードが電子メールアドレスに一致すると、別のサイトで使用できるようになります。攻撃者は2つまたは3つのパスワードを選択する可能性がありますが、おそらく20はありません。この場合も、この制御は効果的ではありません。
では、この制御はどのレベルのセキュリティを確立するのでしょうか？経験の浅いスクリプトキディ、悪意のある元パートナー、およびあなたの個人アカウントを見てランダムに5つのパスワードを試したいせんさく好きな親から保護するために必要なレベル。これ以上ではありませんが、それ以下ではありません。
1それから、もちろん、このコントロールでは軽減されない、キーロギング、（スピア）フィッシング、MitMなど、より高度な他のテクニックもあります。
これで可能なシナリオは2つだけですが、アカウントロックアウト時間のポリシーリスクを示す方が、ロックアウト時間よりも長くなります。
例えば。
ログインをブルートフォースで強制し、3回の試行後に待機するように、hydraまたは他のツールを構成できます。十分なロック時間がないと、アカウントが侵害される可能性があります。
30分程度のロック時間がある場合は、ツールをブルートフォース用に構成して、3回の試行後にパスワードを解読するのに数年かかる可能性があります。
これを結論付けるには、アカウントロックアウトの試行を表示することにリスクはないということです。
私は一般的に、攻撃者に提供する情報が少ないほど優れています。 @ security-beastについて述べたように、適切な時間待機するようにツールを構成できます。その構成の情報を提供することは必ずしも理想的ではありません。
ただし、これをユーザーのニーズとバランスさせる必要があります。ユーザーがアカウントをロックし続けるため、システム管理者がアカウントのロック解除に膨大な時間を費やしていると思いますか？その場合は、分析により、ユーザーに再試行回数を表示して、アカウントをロックする前に待機する必要があるタイミングがわかることで、より多くの利益が得られることが示される場合があります。その他の場合は逆になりますが、どちらの方法でも、特定のシステムのトレードオフを客観的に分析した結果であるはずです。
お役に立てれば。
ある時点で、私は彼らが数人の男にセキュリティをテストさせただけの会社にいました。それらの人が見つけたこれらの事柄の1つは、あまりにも多くの誤ったパスワードが存在するときにアカウントのロックアウトがなかったことです。しかし、CISOが喜んだことに、パスワードを力ずくで押しつけて実際に侵入できることを証明することはできませんでした。これは、アカウントロックアウトがサイレントであり、約15分間続いたためです。
そのようなメッセージを表示することによって何が得られ、そうすることによってセキュリティが失われるかを自問してください。誤ったログイン試行が多すぎるためにアカウントをロックしたことを通知しないことは完全に有効です。あなたがそのようなメッセージを与えるなら、あなたは攻撃者が彼の時間の総当たりの力を浪費しているときを理解するのを助けるだけです。そうしないと、彼らはそれを理解する可能性は低くなりますが、ヘルプデスクへの電話やメールが増えることになり、コストがかかる可能性があります。 FAQまたはヘルプページでこれを減らすことができます。
また、カウントダウンを実装することはおそらく、より多くのコードを意味し、より多くのコードはより多くのバグを意味します。これは、セキュリティメカニズムに必要なものではありません。さらに、間違って実装すると、攻撃者がユーザー名を列挙できるようになる可能性があります。これは、ユーザーが電子メールアドレスの場合、二重に問題になります。地獄、署名されていないCookieを使用して実装した場合、実際には、攻撃者がロックアウトの発生を防ぐことができる可能性があります。
一般に、エラーメッセージにできるだけ少ない情報が含まれていると、セキュリティが向上します。
セキュリティリスクは主観的であり、セキュリティコントロールの目的を保護するために何を試みているか、およびリスクを軽減または補償する適切な他のセキュリティコントロールに依存します。
これに基づいて、異なる会社/ビジネスは同じリスクに対して異なる受け入れをします。
一般的な方法で、試行回数を提供してもリスクを課さない場合があります（例：PINスマートカードで電話をかける））他の状況では、リスクになる可能性があります（例：携帯電話へのブルートフォースアクセスを試みます）、最後の試行の前に停止し、しばらく待って、ユーザーが有効なアクセスでカウンターをリセットできるようにします...
セキュリティ管理の目的、保護しようとしていること、および異常な状況を補正または少なくとも監視するために実施しているセキュリティ管理を確認する必要があります。
このすべてに基づいて、それはそれがあなたの仕様にとって許容可能なリスクであるかどうかを決定できます。