ログイン時にユーザー名/アカウントが存在しないというメッセージを表示するのは安全ですか？
OWASP Auth Guidelines によると、「アプリケーションは、ユーザーIDまたはパスワードが間違っていたかどうかに関係なく、一般的なエラーメッセージで応答する必要があります。また、既存のアカウントのステータスを示しません。」
ただし、アカウントが存在しないというメッセージを表示することで、多くの一般的なWebアプリがこのガイドラインに違反していることがわかりました。
ここで何が起こっているのでしょうか？ Google、Microsoft、Slackは安全でないことをしていますか、それともOWASPガイドラインは役に立ちませんか？
これはセキュリティと使いやすさの間の考慮事項であるため、実際にはrightの答えはありません。だからここに私の意見に従います。
ユーザー名を秘密にできる場合は、秘密にしてください。この場合、ユーザー名が存在するかどうかを判断する方法はなく、ログインはユーザーが存在するかどうかに関係なく同じように反応します。これは、同じ時間でエラーメッセージが返されることも意味することに注意してください。
この動作は可能でない場合があります。たとえば、ユーザーが自分自身を登録して自分のユーザー名を選択できる場合、ユーザー名がシステムにすでに存在する場合はユーザーに通知する必要があります。その場合は、最も詳細なエラーメッセージを提供して、ログインをできるだけ使いやすくします。誰かが登録機能を使用してユーザーが存在するかどうかを把握できる場合、これをログイン時に非表示にしても意味がありません。
大手企業が従わない唯一のOWASPガイドラインではありません。多くの場合、OWASPはセキュリティに焦点を当て、ユーザビリティを無視します。まともなパスワードポリシー、ブルートフォース保護（ロックアウト、キャプチャ、..）、MFA、失敗したログイン試行の監視などと組み合わせると、これは有効な設計上の選択になります。
ユーザーの列挙は、ユーザーアカウントを推測して、後で認証をブルートフォースできるという問題だけではないことを考慮に入れてください。一部のサイトでは、ユーザー（成人、政党、デートなど）のプライバシーを保護する必要があります。上司がアダルトWebサイトを使用しているかどうかを確認したい場合、ユーザー列挙の脆弱性を悪用して、彼が使用しているサイトを知ることができます。
それを防ぐことはできません。（かなりの量のユーザビリティを犠牲にする準備ができている場合を除きます。）
ユーザーの列挙は望ましくない場合があり、実際にセキュリティに影響する可能性があります（たとえば、攻撃者がadminという名前の有効なアカウントがあり、アクセスしようとしていることがわかった場合）。しかし、大規模なサイトの場合、これは発生を止めることはできません。
ログイン中にユーザーが存在しないことを明らかにしなかったとしても、新しいユーザーがすでに使用されている名前またはすでに使用されているメールアドレス。
これを回避するユーザーフレンドリーな方法はありません：
安全性は相対的です。アカウントが存在するかどうかについての情報を提供しない方が少し安全です。しかし、それはその情報を提供することが安全でないことを意味するものではありません。安全性は低く、非常にわずかです。
これは、あなたが与える例で特に当てはまります。アカウント名を見つける方法は他にもあるので、アカウントが存在するかどうかを隠そうとしても意味がありません。
他の形式の security by obscurity と同様に、アカウント名を非表示にすることは弱いセキュリティコントロールであり、他のコントロールが必要です。
@シルバーの回答に同意しますが、拡大したいと思います。コンテキストに留意してください。 OWASPガイドラインは、セキュリティの専門家ではない開発者の経験則として意図されています。ソフトウェア開発会社に優秀なセキュリティアーキテクトのチームがいる場合、彼らがルールの背後にある意図を理解し、他の方法でリスクを軽減している限り、盲目的に経験則に従う必要はありません。
類推：3か月または5,000 kmごとに車のオイルを交換することになっていますが、自動車整備士は、運転習慣が良好であることがわかっている場合、それをより長く押すことがよくあります。そして、それは完全に大丈夫です。
ここでの詳細については、私はユーザー列挙の脆弱性の専門家ではありません。また、GoogleとMicrosoftが決定を下した理由にも精通していませんが、大規模な事態を防ぐためにレート制限とブラックリストを行っていると思いますユーザー列挙攻撃、およびその他の点でユーザーの利便性は追加のリスクに値すると判断しました。
OWASPガイドラインに違反しているとは言い難いでしょう。GoogleやMicrosoftのようなアプリケーションやサービスでは、可能な限り「ユーザー準拠」である必要があるためです。
さらに、それらはすべて2FAプロトコルを備えているか提供しています。
アクティブなユーザーIDを開示しないことの目的は、多数のアカウントの列挙を防ぐことです。
厳密に言うと、アカウントの重複を許可することでこれを防ぐことができますが、これはひどい設計であり、あらゆる種類のトラブルにつながります。
これを行う別の方法は、assignユーザーに識別子を使用することです-未使用の識別子を作成します。しかし、これは使い勝手が悪いので、価値がないかもしれません*。
リスクを軽減するための賢明な方法は、任意の抗列挙機能を実装することです-たとえば、列挙の試みを遅くするための良質なキャプチャ。その後、設計はかなり安全です。
残存リスクは、非常に価値の高いアカウントの検証を開いたままにすることです-たとえば、barack.obama @ gmail.com。次に、パスワードクラッキングの試みに対する制御なども実装することにより、このリスクを軽減します。
* Salzer and Shroeder、 The Computer of in Information in Computer Systems 、Section IA3）h）心理的受容性：ユーザーが日常的かつ自動的に適用できるように、使いやすいようにヒューマンインターフェイスを設計することが不可欠です。保護メカニズムを正しく。また、保護目標のユーザーの精神的イメージが、ユーザーが使用しなければならないメカニズムと一致する限り、間違いは最小限に抑えられます。彼の保護ニーズのイメージを根本的に異なる仕様言語に変換しなければならない場合、彼は間違いを犯します。