間違ったパスワードまたはユーザー名の一般的なエラーメッセージ-これは本当に役に立ちますか？
ユーザーがログインしようとしたときにユーザー名またはパスワードが間違っていた場合に、ログインページに表示されないのは非常に一般的です（そして、ある種のセキュリティの基本だと思います）。代わりに、「パスワードまたはユーザー名が間違っています。」.
その理由は、どのユーザー名が既に使用されているかを潜在的な攻撃者に示すことではないため、既存のアカウントを「ハッキング」するのが難しくなります。
私には理にかなっているように思われましたが、その後、何か違うことが思い浮かびました。
アカウントを登録するときに、ユーザー名を入力します。そして、それがすでに取得されている場合、エラーメッセージが表示されます-これは一般的ではありません！
つまり、基本的には、攻撃者は登録ページから「正しい」ユーザー名を取得するだけか、それとも私は間違っているのですか？
では、一般的なメッセージのポイントは何ですか？一般的でないメッセージは、はるかに優れたUXにつながります。
いいえ、あなたは正しいです。攻撃者が有効なユーザーIDを特定できないようにするためのある時点で、嘘をつくか、非常にあいまいなエラーメッセージを提供する必要があります。
アプリは、「要求されたユーザー名は使用できません」とユーザーに伝えることができ、すでに使用されているか、他のユーザー名の要件（長さ、文字の使用、予約語など）を満たしていなかったかを特定できません。もちろん、これらの詳細が公開されている場合、攻撃者は、無効な形式ではなく、使用中のアカウントが原因で推測が失敗したことを突き止めることができます。
次に、パスワードリセットシステムもあります。ユーザー名/メールアドレスを受け入れ、そのアカウントがデータベースにない場合でもメッセージが送信されたと言いますか？アカウントロックアウト（使用している場合）はどうですか？認証情報が無効であったとしても無効であるとユーザーに伝えただけで、代わりにアカウントがロックアウトされ、問題を特定できるカスタマーサポートに連絡したいと考えていますか？
攻撃者が有効なユーザー名を収集する難易度を上げることは有益ですが、通常はユーザーを苛立たせます。私が見たセキュリティの低いサイトのほとんどは、ユーザーを幸せに保つためにエラーを好むという理由だけでユーザー名またはパスワードが間違っているかどうかを識別する個別のメッセージを使用しています。セキュリティ要件がユーザーエクスペリエンスよりも優先するかどうかを決定する必要があります。
あなたは、システムが実際にどのフィールドが間違って入力されたかを知っているという仮定をしている。これが必ずしも正しくない理由はいくつかあります。
1つの可能性は、それが実装の副作用であることです。データベースでログインを検索する単純な方法は次のようになります（ユーザーが指定したパラメーターに:nを使用）：
SELECT 1
FROM users
WHERE username=:1 AND
password=HASHING_FUNCTION(CONCAT(:2, salt))
空の結果が表示された場合、ログインは失敗するはずですが、より複雑なことをしたり、別のクエリを実行したりしない限り、その理由はわかりません。したがって、意識的なセキュリティの決定ではなく、ただのんびりしたり、データベースを使いやすくしたい場合があります。
ただし、実装で存在しないユーザーと誤った資格情報を区別できる場合でも、ユーザーはパスワードを正しく入力しているが、ユーザー名は間違っており、存在するユーザー（別のパスワードを使用している）である場合があります。次に、ユーザーが自分のパスワードが間違っているというメッセージを受け取った場合、それは間違いです。したがって、指定されたユーザー名が存在しない場合を除き、システムできないは、ユーザー名またはパスワードが間違っていたかどうかを実際に認識します。
一般に、登録ページをブルートフォースするよりも、登録ページをブルートフォースするほうが難しいので、この追加コストの恩恵を受けます。しかし、概念的には、あなたは正しいです。ユーザー名を列挙するには、ログインページメッセージ以外の方法があります。
攻撃者が良好なアカウントを不良アカウントから収集することを困難にするために、ログイン失敗メッセージを汎用的に維持するのは、単に「グッドプラクティス」（TM）です。ブルートフォースツールを使用すると、ランダムな名前を試し、エラーメッセージが変化したときに、そのユーザー名をブルートフォースで強制することは簡単です。
しかし、いつものように、ユーザビリティと脅威の軽減のバランスをとる必要があります。
すべてのシステムにアカウント登録があるわけではありません。たとえば、オペレーティングシステムのログインではできません。ウェブサイトは時々新しいメンバーを受け入れるのをやめます。
それは問題の分離の問題です。ログインダイアログはシステム構成を照会し、システムが新しいアカウントのアプリケーションを受け入れるように構成されているかどうかに基づいてその動作をカスタマイズする必要がありますか？次に、ログインダイアログは、そのジョブに実際には関係のない情報に結び付けられます。
すべてのケースで漠然としたエラーメッセージを実装する方が簡単なようです（UIソフトウェアがパスワードが悪いのか、アカウントが存在しないのかさえわかっていると仮定すると、何らかの下位レベルのAPIから一般的な認証エラーが発生した場合はどうなりますか？）
また、新しいユーザーアプリケーションのUIは、「ユーザーベースを検索しています... [10秒] ...おっと、ユーザー名は既に使用されています！」これが実装されている場合、これは、このメカニズムを介してユーザーIDのスペースをプローブすることがレート制限が厳しいことを意味します。新しいアカウントの申請はまれな1回限りの操作であるため、ユーザーは遅延に苦しむことになりますが、通常のログインダイアログでは10秒の遅延によって悪化します。
ユーザー名が何であるかによります。ユーザー名には主に3つの方法があります。
- ユーザーが選択した名前
- 電子メールアドレス
- 割り当てられたユーザー名-通常は数字の文字列
ユーザーが選択した名前について、攻撃者は登録プロセスを使用して、どの名前が使用されているかを推測できるため、ログインが一般的なメッセージを返すメリットは限られています。
ただし、他の2つのケースでは、ログイン画面が一般的なエラーメッセージを返すことがはるかに重要です。採用サイトを考えてみてください。上司に採用サイトにアカウントがあることを発見させるのは[email protected]にとって恥ずかしいことです。また、割り当てられたユーザー名は、オンラインバンキングなどのセキュリティの高いサイトで最もよく使用されます。
はい。それで合っています。ユーザー名が存在するかどうかを確認できるサイトのどこでも sername enumeration につながる可能性があります。
ただし、システムにとって重要な場合は この問題は解決できます 。一部のシステムでは、ユーザー名の列挙はアプリケーションの性質に固有であるため、回避できません。 1つの例はWebメールサービスです。ここでは、電子メールアドレスは公開されている可能性があります。ユーザーが他のユーザー名を知るのを防ぐことは、ホストされている電子メールアドレスとは異なる識別子でログインすることをユーザーに要求することなく困難であり、失われた資格情報を回復するのに混乱と困難につながる可能性があります。
ただし、他のほとんどのシステムでは、ユーザーの電子メールアドレスをログインユーザー名として使用することでこれを修正できます。忘れたパスワードとサインアップフォームを事実上同じページにすることで問題を解決します。サインアップの場合、これは複数ステップのフォームであり、最初のステップは、ユーザーがシステムで使用したいユーザー名（メール）を要求するだけです。アカウント復旧の場合、これは同じ形式になりますが、タイトルはPlease enter your email address to generate a password recovery email。
どちらの場合も、フォームはユーザーにメールを送信します。彼らがすでにサインアップしている場合、このメールの内容にはパスワードリセットリンクが含まれています。サインアップしていない場合、このメールの内容にはサインアッププロセスの次の段階へのリンクが含まれています。これにより、システムのユーザー名が列挙されなくなるため、攻撃者はどのアカウントを対象にするかを知ることができません。
もちろん、これは、パスワードを電子メールでリセットできるようにする用意があることを意味します。これは、銀行アプリケーションなどの一部のアプリケーションでは受け入れられない場合があります。ただし、これらの種類のアカウントには通常、追加のセキュリティチェックがあるため、通常は銀行がユーザー名を割り当てるのではなく、ユーザー名を割り当てます。
共通の引数for曖昧なメッセージは、攻撃者が有効なユーザー名を推測できないようにするためのものです。実際には、正当なユーザーに深刻な影響を及ぼさない簡単なソリューションがあり、いずれにせよ、一定期間内に失敗する最大試行回数を制限する必要があります。
試行を制限することにより、総当たり攻撃をすべて防ぐことができます。 15分間に5回の試行のみを許可するとします（フォーラムでは一般的です）。これにより、ユーザー名を推測する攻撃が役に立たなくなります。また、パスワードのブルートフォーシングを防止します（リモートサイトの場合と同じように無用に遅くなります）。
もちろん、攻撃者はすでにユーザー名のデータベースを持っている可能性があり、ユーザーが自分のサイトに存在するかどうかを確認したいだけです。そして、そのセキュリティへの影響を考慮する必要がありますが、通常はパスワードが既にある（この議論を無効にする）か、持っていません（そのため、制限された試みはとにかく推測を防ぎます）。
ユーザー登録ページでのユーザー名の列挙を回避するために、アプリケーションは、ユーザーに選択肢の1つを選択するように求めるのではなく、ユーザーの電子メールアドレスに基づいて自動的にユーザー名を割り当てることができます。
これにより、ユーザー名の列挙や登録ページを防ぐことができます。
また、忘れたパスワード機能を考慮に入れる必要があります。これにより、有効なユーザーの詳細も明らかになる場合があります。
スマートなWebサイトでは、このようなことを防ぐために、登録ページにキャプチャが表示されます。
しかし、あなたはウェブサイトの99％がいかに知っている。彼らは余分なセキュリティを提供していなくても、一般的なエラーメッセージでUXを台無しにします。個人的には、ログインに他の多くの制限（キャプチャ、制限されたログイン試行）があり、ログインが人々がウェブサイトを捨てる最大の理由のようなものなので、私は一般的なエラーメッセージを気にしません。
一般的なエラーメッセージを表示することを選択した場合は、それで問題ありません。どこにも緩い端がないことを確認してください。 10インチの厚さの鋼で壁を補強することもできますが、ドアにロックされていないドアがある場合、それは役に立ちません。
私は攻撃者の帽子をかぶろうとしていますが、2つのケースが表示されます。
サイトに登録ページ（GmailやStackoverflowなど）があります。登録ページを使用して、ブルートフォースで既存のユーザーのユーザー名を調べることができます。または、新しいユーザーを作成することもできます。私の新しいGmailまたはStackoverflowユーザーは、私が強引に強制したものとほぼ同じ権限を持っているでしょう。
あなたのサイトには登録ページがありません。あなたの主張は無効です。