私はウェブサイトの責任者であり、遵守を求められた「業界標準」ポリシーの論理について質問しています。
ユーザーがWebサイトにログインすると、ログインの詳細が正しくないことを通知するメッセージが表示されますが、ユーザー名とパスワードのどちらが正しくないかは明記していません。
ユーザーがパスワードを忘れたことに気付いた場合(パスワードマネージャーを使用する必要がありました)、パスワードを忘れた場合のリンクをクリックし、電子メールアドレスを入力してEnterキーを押します。次に、アカウントを持っている場合、アカウントはロックされており、パスワードリセットのメールがメールアカウントに送信されていることを通知するメッセージが表示されます。
これまでのところ、どの資格情報が正しくないか、または提供された電子メールにアカウントが存在するかどうかに関する情報の漏洩はありません。
ユーザーエクスペリエンスを向上させるために、ユーザーがパスワードを忘れた場合のリンクをクリックした場合、ログインフィールドにある場合は、パスワードを忘れた場合のページのメールアドレスフィールドにコピーすることをお勧めします。
しかし、これを裏付けるために私に何かを見せることはできませんが、これは「業界標準」に違反していると言われています!
URLに追加するだけでは悪いことだと私は理解しています。これは、ユーザーがメールアドレスを循環してユーザーのアカウントをロックアウトし、ユーザーに不便を与える可能性があるためです。
どのようなセキュリティの脆弱性があるとすれば、これは悪い習慣になりますか?
編集:
新しい読者のためのアップデート。
ここでいくつかの素晴らしい答えがありました、そして、私はすべての入力に感謝しています。
プロセスには、忘れられたパスワードのロックアウトに欠陥があり、これは修正されます。ロックアウトされたアカウントがemail address or password incorrect
メッセージが表示されるため、ユーザーはメールアドレスが有効であることを知りません。
それ自体なし
提案している変更は、ユーザーエクスペリエンスの変更にすぎないようです。はい、誰かが悪意のあるユーザーがシステムから通常のユーザーをロックアウトすることはユーザーフレンドリーになると言うことができますが、それはあなたにはありません。
より大きな問題は、ユーザーがパスワードを忘れたときにクリックしたときにユーザーのアカウントをロックするというポリシーです。悪意のあるユーザーがあなたをあなたのアカウントから簡単に締め出すことができます。彼らはパスワードを忘れたところに行く必要があります->有効なメールIDを入力してください->リセットボタンを押してください。
ここでは大きな問題はありませんが、キャッシュを無効にして、同じブラウザーでページにアクセスしたユーザーが、パスワードを忘れた場合のページを読み込んだ場合にメールアドレスにアクセスできないようにします。
ヘッダーの推奨事項 ここから 。 pragma
はHTTP 1.0の仕様による要求ヘッダーですが、多くのブラウザーやプロキシサーバーは、応答で指定された場合でもそれを解釈することに注意してください。
Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0
また、パスワードを忘れた場合のページへのリダイレクトをPOSTすることで、クロスドメインリファラーの漏洩とブラウザーの履歴への保存を軽減する必要があります。
次に、アカウントを持っている場合、アカウントはロックされており、パスワードリセットのメールがメールアカウントに送信されていることを通知するメッセージが表示されます。
アカウントのロックは、特定のユーザーに対するサービス拒否攻撃として行われる可能性があります。 [email protected]があなたのシステムにアカウントを持っていることを知っていて、彼のサービスを拒否したい場合、彼をロックアウトし続けるために、そのアカウントのパスワードのリセットを繰り返し要求することができます。
ユーザーがWebサイトにログインすると、ログインの詳細が正しくないことを通知するメッセージが表示されますが、ユーザー名とパスワードのどちらが正しくないかは明記していません。
アカウントがロックアウトされている場合、何を表示しますか?
ユーザー名とパスワードが間違っていると言った場合、ユーザーが実際にロックされていると混乱する可能性があります(上記の私のDoSの説明に従って)。
ただし、彼らのアカウントがロックアウトされていると言う場合、存在しないアカウントに対してもこれを行っていますか?そうでない場合は、攻撃者としてパスワードのリセットを試み、すぐに同じユーザーとしてログインを試みることができるので、私は尋ねます。その後、アカウントがロックされているというメッセージが表示された場合、有効なアカウントを発見しました(これは ser Enumeration 脆弱性として分類されます)。
したがって、パスワードのリセットが試行された場合、存在しないアカウントをロックするようにロジックを見せることもできます。ランダムな期間の後、これらのロックを解除するように見せることができます。そうしないと、永久にロックされたアカウントは、ロックが解除されたことがないために存在しないアカウントであると攻撃者が推測する可能性があります。
ユーザー名を忘れたパスワードのページにコピーするときに、あなたが破った「業界標準」を見ることができません。
私の知る限り、有効なユーザー名と無効なユーザー名(電子メールアドレス)に対して同じメッセージを表示している限り、これを忘れたパスワード機能に送信しても問題ありません。
I.E.有効または無効な電子メールアドレスに関係なく、ユーザーには次のメッセージが表示されます。「ありがとうございます。提供された電子メールアドレスでアカウントが作成されている場合、その電子メールが送信されます。アドレス、パスワードをリセットするための指示付き。」
私が問題を確認できる唯一の方法は、ユーザー名フィールドがオートコンプリートで有効になっている場合です。明らかに、ユーザーが共有コンピューターを使用している場合、ユーザー名(電子メールアドレス)が攻撃者に開示される可能性がありますが、それはすべて、ここで説明しているWebサイトの種類によって異なります。
潜在的なセキュリティの欠陥はさておき、これは、顧客が電子メールアドレスを正しく持っていると思っていることは正しく、間違っていたのはパスワードだけであるという仮定に依存しています。
メールアドレスを誤って入力しても、すぐにこの事実に気付かないお客様は、パスワードのリセットにヒットし、メールアドレスが自動入力され、自動入力されたメールアドレスを再確認することなく[パスワードのリセット]をクリックします。電子メールフィールドのタイプミスに気付かれない場合があり、ユーザーは、電子メールアドレスが一目で正しいように見える場合、パスワードが間違っていると思い込む可能性があります。
その後、パスワードが[email protected]に送信されたために、これまで届かないパスワードのリセットをしばらく待ちます。
彼らの次のステップは、あなたのビジネスの性質に応じて、カスタマーサポートに電話をすること、同じ製品を持つ競合他社を見つけることなどです。ここの空白の記入はどれもあなたにとって良いことではありません。
パスワードを忘れた場合のオプションを選択し、ログインIDが(一部のサイトで使用されているようなユーザー名ではなく)メールアドレスであると想定した場合、メールアドレスを[メールアドレス]フィールドに入力することをお勧めします。
これは私の見解ではセキュリティ上の問題ではありません。ユーザーが忘れたパスワードリンクを選択したときにサーバー側のリクエストを行う必要があるように見えるはずです。では、忘れてしまったパスワードUIコンポーネントが、シングルページアプリのようないくつかの方法で既にプリロードされていないのはなぜですか。では、忘れたパスワードのリンクを選択してから、忘れたパスワードビューを表示しますか?
私はあなたが破った業界標準を知りません。
一般に、正しいプロセスに従っていますユーザーが「無効な認証情報」で応答した認証情報を入力し、それ以上の情報を提供しない場合は、正しいことです。
忘れたパスワード変更の「ビュー」を選択し、電子メールアドレスを入力し、ユーザーが送信を選択できるようにすると、サーバーの応答は「パスワードを忘れた電子メールが発行されました」になります。
Forgotten Password Pageを取得するためにサーバー側のリクエストを行う必要がある場合は、パラメーターがGETリクエストに含まれていてはならないことが正しく識別されています。これは、サーバー側のログにクエリ文字列パラメーターが格納されるためです。インフラストラクチャと管理ユーザーによって、これらの管理ユーザーがこれらのアカウントを知ることを許可する場合と許可しない場合があります。
ログインページに既に入力されている電子メールアドレスをパスワードリセットページにコピーすることはnotセキュリティ上の欠陥です。
唯一の違いは、リセットするために、パスワードを忘れた場合のボックスにユーザーが知っているアドレスを再入力する(または盗む)必要があるかどうかです。彼らはすでにこの情報を持っています。ログインからリセット画面にユーザー提供のデータをコピーすることにより、ユーザーに不明なデータが漏洩することはありません。電子メールは目に見える形で確認されず、リセットプロセスでは何も変更されません。文字通り唯一の違いは、ユーザーがメールアドレスを2回入力する必要がないことです。
彼らは自分の電子メールまたは盗まれた電子メールを知っているので、これは何も明らかにしません。これは、コピーして貼り付けたり、再入力したりするのと同じです。