web-dev-qa-db-ja.com

間違った認証情報を何度も入力すると、アカウントがロックされることをユーザーに伝えるにはどうすればよいですか。

ユーザーが何度もログインに失敗した場合(製品で設定可能ですが、おそらく5〜10分)にユーザーアカウントを短時間ロックすることで、製品にセキュリティの層を追加します(設定も可能ですが、デフォルト設定はおそらく5回程度です。

これをユーザーに提示するのに最適な方法を見つけようとしています。

オプションA:ユーザーがログインに失敗して失敗するたびに、残りの試行回数をカウントダウンします。 「残り3回のログイン試行があります」、「残り2回のログイン試行があります」など。このアプローチの問題は、私が見る限り、ログインプロセスに不要でストレスの多いコンポーネントが追加されることです。一方、最初のエラーの直後に、アカウントがロックされるまでの試行回数が非常に多いことが通知された場合、パスワードを入力するときに、ずさんにならないでしょう。

オプションB:最後の試行の前にのみ警告を表示します。例えば。 「セキュリティ上の理由から、間違った資格情報をもう一度入力すると、ユーザーアカウントはX分間ロックされます。」このアプローチは、ユーザーが実際に必要になるまで不要な情報を避け、私はこのオプションに頼っています。

あなたの考えは何ですか?他にもっと良い方法はありますか?

9

TL; DR-多くの人がこの機能を追加しているのを見てきましたが、これは純粋なセキュリティシアターでした。それはユーザーを助けておらず、サイトをより安全にするものではありません。可能であれば避けてください。

ロングバージョン...

個人的に-私はこれが実際に追加するのに良い機能であるかどうか疑問に思うでしょう。実際にシステムをより安全にしますか?安全にするためのより良い方法はありますか?

ここでは、Webベースのアプリケーションであると想定しています。ログインは純粋なユーザー名/メールアドレスとパスワードであると想定しています。これらの2つの仮定が正しくない場合、これの一部は適用されません。

  • 人々は実際にシステムをクラックしようとしていますか?これは本当の問題に対処していますか、それとも人々thinkが起こる/起こっている問題ですか?後者の場合、機能を追加する前にこれが問題であったという証拠があるように私は非常に懸命に戦います。かつて私が作業した場所はsureパスワードの試行に何度も失敗したため、ハッキング攻撃を受けていました。調査の結果、多くのユーザーがパスワードを忘れてしまったことがわかりました...別のクライアントは、ログインボックスに電子メールアドレスとURLを投稿しているスパムボットであることがわかりました。最初に確認してください。ユーザーのロックアウトは、セキュリティをほとんど追加せず、リスクを追加し(下記を参照)、ユーザーの仕事にストレスを与えます。

  • アカウントロックアウトを追加すると、すぐにサイトがサービス拒否攻撃を受けやすくなります。最も深刻なクラッキング攻撃は質量一般にサイトを標的とした攻撃であり、個人を標的とした攻撃ではないことを覚えておいてください。彼らは何千/何百万ものユーザー名/パスワードの組み合わせを試します。突然、何千人ものユーザーがアカウントからロックアウトされました。これにより、サポートセンターに電話やメールで過負荷になるロールオン効果が発生します。これはあなたのサポートが失敗する原因になります。これは、サービスがいかにひどいことについて人々を悩ませ、うめきます。 PR地獄へようこそ。私はこれが今二度起こるのを見ました:-)

  • ロックアウトはほとんどの場合役に立ちません。クラッキングの試みは主に大量攻撃であるため、クラッカーは気にしません。彼らは次のアカウントに移動し、N分後に戻って続行します。

これが発生している場合は、単純なログイン失敗試行回数のカウンターを超えるよりも、それを解決するための優れた手法があります。たとえば、次のすべての組み合わせ:

  • N番目の試みで、追加の認証手法の導入を開始します。誕生日、CAPTCHA(数回のうちの1つは妥当なオプションだと思います:-)、セキュリティの質問への回答など。3番目の情報を追加することで、クラック攻撃を困難にします。

  • ユーザーにパスワードリセットメカニズムを案内し、ユーザーが明らかに忘れたパスワードを回復する自動メカニズムを提供します。

  • ユーザーを締め出すのではなく、ログインプロセスに一時停止を導入し始めます。最初のポーズを短くし、複数回試行した後のポーズを長くします。スロットルはクラッカーボットに人間規模の試行回数を強制的に落とさせるため、リスクを劇的に削減し、ランダムにパスワードを推測するのに十分ではありません。

14
adrianh

標準のセキュリティ慣行では、進行中のプロセスについて何も漏らしません。これは、システムへの不正アクセスを支援するためです。

これは、「あと2回試行しています」などのメッセージでは特に必要な考慮事項ではないかもしれませんが、アカウントがロックアウトされる期間をユーザーに伝えないでください。セキュリティモデルに関する情報が多すぎます。

同様に、どのトークンが間違っているか、ユーザー名が認識されないか、パスワードが正しくないかについてのヒントを決して与えないでください。ユーザー名が間違っているというメッセージは、クラッカー*に再度使用しないように伝えます。パスワードが間違っているというメッセージは、ユーザー名が有効であり、パスワードを試すだけでよいことを彼に伝えます。常に一般的な「無効なログイン」メッセージを表示します。

これはどれも、失われたパスワードを回復するための支援を提供することを排除しません。

これらのことは、プロセス中にヒントを与えるのではなく、導入トレーニング中に新しいユーザーに伝達する必要があります。また、(既存のユーザーに導入された新しいセキュリティ体制の場合)メールショットでユーザーに直接、またはシステムメッセージとして伝達する必要があります。再度ログインしました。


*はい、クラッカーではなくクラッカーです。 違いについてのエリックSレイモンド

5
Andrew Leach

オプションBが私にとって最も論理的な解決策のように思えます。あなたが言ったように、オプションAは、ストレスの多いコンポーネントをログインプロセスに追加し、私が残した試行回数を通知するだけで、パスワードをより速く覚えることはできません。

オプションBの提案はありますか。

コピーを気にする必要があるかどうかはわかりませんが、気になる場合は、大幅に短くして、要点を明確にします。そして、可能であれば、ユーザーをソリューションに導きませんか?したがって、1回の試行が残っていることだけを伝えないでください。また、パスワードを本当に紛失した場合に、ユーザーがパスワードを取得できるようにしてください。

例:

「セキュリティ上の理由から、1回の試行が残っています。 パスワードをお忘れですか? "

1

オプションC:

何も起こらずに1つのエラーを発生させます。 (これは、「タイプミスを犯したことを知っています」の状況をカバーしています)

次に、2番目のエラーでオプションAのカウントダウンシーケンスが表示されます。

1
PhillipW