「パスワードを忘れた」のはなぜですか？リンクは一般的にユーザー名または登録されたメールアドレスを明らかにしますか？
ほとんどのサイトまたはシステムは単に述べているようです
無効なユーザー名またはパスワード
総当たり攻撃（およびその他の攻撃）で使用するためにユーザー名を明らかにしない手段として。原則として良い考えのようです。しかし、それらの多くはパスワードを忘れましたか？リンクをたどることができ、多くの場合、
このメールアドレス/ユーザー名は登録されていません
これは同じプロセスに従わず、この情報を明らかにすべきではありませんか？
標準になったのは、単に悪い設計慣行ですか？
編集して追加します。ユーザーが自分で登録できず、一般の人もアクセスできないような安全なシステムを考えています。だから、それはアクセス権を持つ人たちに保護されるべきであり、それだけです。
はい、それは確かに悪いセキュリティ慣行です。
パスワードを忘れた場合の機能を使用する場合、サイトは次のメッセージで応答する必要があります。"指定された電子メールアドレスに電子メールが送信されました（存在し、システムに登録されている場合）。 。 "
または単に「アカウントのリセット手順が正当なアカウント所有者によって開始されたと想定して差し支えないので、パスワードをリセットするための手順については、電子メールの受信トレイを確認してください」。
編集：攻撃者は、電子メールアドレスがシステムに登録されているかどうかを、そのアドレスでアカウントを開こうと試みることによって見つける可能性があることが指摘されています。この攻撃を阻止するには、登録手順も変更する必要があります。ユーザーは、次のようにメールアドレスを確認した後にのみ登録を許可する必要があります。
新規登録用のメールアドレスを入力すると、サイトから次のメッセージが返されます「メールは指定されたメールアドレスに送信されました。必要に応じて、メールを読み、指示に従って登録を完了してください。」 。次に、電子メールメッセージには、登録を完了するための手順、または電子メールアドレスがすでに登録されている場合はユーザーへの簡単な警告が含まれます。
いくつかのWebサイトがその「セキュリティ」測定に従う理由はあります：セキュリティを獲得せずにユーザビリティ（およびユーザー）を失うことになります。
セキュリティのヒントが最も小さいWebサイトでも、パスワードを「推測」できる回数に制限が適用されますORユーザー名。既存のすべてのユーザー名を繰り返し使用しないようにするため、この制限は、登録、ログイン、パスワードの回復など、すべての面に課す必要があります。
「一般的なエラーメッセージを表示するのが非常に悪い場合、なぜ人々はそれを行うのですか？」答えは、セキュリティが若く、未発達だった遠い過去から来ています。認証はオフラインまたはローカルネットワークで行われることが多く、攻撃者はプロセッサが許す限りの速さでブルートフォースを実行できました。無制限の数の推測が急速なペースで発生しているため、システムがユーザー名が存在するかどうかを報告した場合、存在するすべてのユーザー名を繰り返し処理することは簡単でした。
大企業（たとえばFacebook）には、ユーザビリティテストを実行するUI/UX部門があり、反ユーザビリティセキュリティシアターのために失われたユーザーの数を示している傾向があります。しかし、多くの小規模企業はUI/UXリソースを持っていないため、このような「ベストプラクティス」を実行することになり、さらに「 セキュリティイメージ 」のように馬鹿げたことになります。
ここには考慮すべきいくつかの問題があり、いくつかはあまりにも頻繁に引用されており、あいまいなことによるセキュリティの誤解を招くステートメントが引用されています。
あいまいなステートメントを通じてセキュリティに対処する。何かを不明瞭にしても、不明瞭さによってセキュリティが自動的に暗示されるわけではありません。あいまいさによるセキュリティの概念は、セキュリティのあいまいさにのみ依存する慣行を指します。セキュリティ制御にあいまいさを組み込むことは完全に許容可能であり、場合によっては良い習慣ですらあります。
違いの例として。 Telnetはパスワードをプレーンテキストで送信するため、本質的に安全ではありません。 Telnetサービスを標準ポートから他のポートに移動し、これがセキュリティの問題に対処したと信じているのは、あいまいさによるセキュリティです。プレーンテキストのパスワードが送信されるという根本的な問題は解決されておらず、セキュリティを維持するために、非標準ポート宛てのトラフィックを誰も盗聴しないようにしています。
一方、sshサービスを標準以外のポートに移動することもできます。この決定は、あなただけがログインするシステムを使用していて、sshを介したブルートフォースアクセスへの多くの試みに気付いたことが原因である可能性があります。このサービスを別の非標準ポートに移動すると、sshサービスに対するブルートフォースの試行回数が減ります。それを使用するのはあなただけなので、それは重大な不便を表すものではありません。そのサービスはより不明瞭になっていますが、別のポートに移動することが唯一のセキュリティ保護ではないため、不明瞭によるセキュリティとして分類されていません。脅威にさらされることは減りましたが、sshサービスに必要な他のすべての標準的な優良事例をまだ使用しています。
セキュリティの不明瞭さは一般的なコントロールであり、信頼できるコントロールがそれだけではない場合は、まったく問題ありません。
パスワードの回復操作を実行するときに電子メールまたはユーザー名が有効であるかどうかを示す元の質問に関しては、それは本当に他の多くの要因に依存しています。セキュリティコントロールは、それらが適用されているコンテキスト内で評価する必要があります。一般的な「ベストプラクティス」のガイドラインがありますが、これらは単なるガイドラインであり、ルールではありません。一般に、攻撃者が攻撃を支援するために使用できる情報を攻撃者に提供することは望ましくありません。ただし、保護しているリソースの価値も考慮する必要があります。
たとえば、RSSフィードリーダーサービスを使用しています。私にとって、これは低リスクのアプリケーションです。攻撃者にとってはそれほど価値はありません。パスワードを忘れて、パスワードを忘れた場合の機能を使用しようとすると、間違ったメールアドレスを持っていると通知するのではなく、失敗したことが通知されるだけで、必要以上に苛立たしいでしょう。入力した住所にタイプミスがあった可能性があり、住所が間違っていると言われた場合は本当に役に立ちます。そのとき問題は私が入力したものにあることを知っています。一般的すぎると言うと、何が問題だったのかを診断できなくなります-入力したのは何か問題だったのですか、サーバーの問題ですか？
一方、私はおそらく自分の銀行が忘れたパスワード機能を使用して、攻撃者に私のアカウント名などの追加情報を提供することを望まないでしょう。この場合、おそらく、パスワードを忘れた場合の機能が失敗したことを示し、電話サポートに連絡するように依頼するメッセージの方が適切でしょう。一方、問題が私のGmailアカウントにある場合は、サーバーへの基本的なSMTPコマンドを使用するだけで有効なメールアドレスと無効なメールアドレスを判別するのは簡単なので、おそらく私はそれほど心配していません。
基本的なポイントは、ユーザーエクスペリエンスとセキュリティのバランスをとる必要があるということです。脅威ベクトルとは何か、保護されているリソースに対する適切な制御は何かを理解する必要があります。常にこれまたはそれがあるべきではありません-それはすべて文脈に帰着します。
はい、それはあなたが述べる理由のために、悪い習慣です。
この種のものを書くとき、私は"Eメールがこのアドレスに送信されました"の行に沿って一般的なメッセージを与えます。アカウントが存在したかどうかは関係ありません。
ただし、このようなフォームを使用してハッカーがどのアドレスが登録されているかを確認しようとすると、アドレスが見つかったユーザーに電子メールが送信されるのを緩和する要素があります。これはユーザーへの警告として役立ちます。実際、一部のサイトでは、ユーザーがリセットを要求しなかった場合の潜在的な攻撃に注意するために、メールに警告メッセージが含まれています。
これは、ハッカーがリセットフォームを使用してアドレスを取得しようとするのを防ぐのに十分な場合があります。
@Ahueahuehauehuaが言ったように、私の意見でも@ dr01の回答はユーザーエクスペリエンスに優しいものではありません。
Always remember that security through obscurity IS NOT a valid approach.
Invalid username or passwordは、ユーザー名とパスワードが一致しない、つまりユーザー名またはパスワード（あるいはその両方）が正しくないことを示しています。したがって、いずれの場合でも、セキュリティのため（まったく安全ではない）ではなく、ユーザー名またはパスワード、あるいはその両方が正しくないため、Invalid username or passwordのようなメッセージを表示します。
最善の方法は、あいまいさではなく、ベストプラクティスによってサインインセキュリティを強化することです。サインイン/サインアップ/パスワードを忘れた場合の再試行を制限してください。たとえば、5回の試行/ IP /時間と5回の試行/ユーザー名/時間に制限します。また、最大試行回数を24時間に設定します（たとえば、10回の試行/ IP/24時間および10回の試行/ユーザー名/ 24時間）。したがって、ユーザー名ごとに1年で3650個を超えるパスワードを推測することはできません。
もう一度言いたいですsecurity through obscurity is not a valid approach.