パスワード リセット Web アプリケーションがあります。アプリケーションは、代替電子メールに確認コードを送信します。私のマネージャーは、コードを入力する必要があるページへのリンクを含めるのは得策ではないと考えています。
私は彼の主張を理解しています。ただし、ヘルプデスクは、プロセスについて混乱しているユーザーで圧倒されています。これは、多くのユーザーが 1 つのタブ/ウィンドウのみを使用してブラウジングし、Web アプリケーションから移動して確認コードの電子メールをチェックしているためだと推測しています。
私の質問: この問題にどのように取り組むべきですか? ヘルプデスクを軽減し、ユーザーの負担を軽減したいと考えています。助言がありますか？
彼は、確認できない送信者からのリンクをクリックするようにユーザーを訓練することで、ユーザーに不利益を与えていると考えています (この場合、「返信なし」アドレスの自動メッセージです)。これにより、ユーザーは、組織内で多くの問題を抱えてきたフィッシング攻撃の影響を受けやすくなります.
頭に浮かぶ唯一のことは、電子メールの件名に一意の識別子を含めるオプションと、顧客にそのメールに返信させるオプションです。
次に、自動化されたスクリプトが「password-forgotten@mycompany.de」をチェックして、「Re: パスワードをお忘れですか?」という件名のメールを探します。[一意のID]'。その後、スクリプトは新しいパスワードをメールで送信します。
ほとんどのユーザーは「返信先」を押したときに件名を変更せず、「新規メールの作成」を実行して受信者アドレスを手動で入力しないため、可能性は高く、「パスワードを忘れた」宛ての受信メールには UNIQUEID が含まれます。件名。
さらに、ヘルプデスクは、電子メールの「件名」を実際に変更する人だけを助けます。;-)
ただし、セキュリティ上の考慮事項があります。マネージャーは、誰かが偽造の「パスワードを忘れた」メールを送信し、「Reply-To」ヘッダーを攻撃者のアドレスに設定する可能性があると主張するかもしれません。処理スクリプトは、これらの偽造の試みを阻止する必要があります...
リンクを送るのが標準的な方法だと思います。顧客がこの電子メール アカウントの整合性を本当に心配している場合は、まずそれを整理したほうがよいでしょう。
基本的に、リンクを送信しないことで余分なセキュリティが得られるわけではありませんが、多くの快適さが得られます. 他のみんなと同じようにやってください - そこに入れてください (時間制限あり)。
特にコードがハッシュのようなものである場合、誰かがクラックする可能性はほとんどないため、リンクを含めるべきではない理由はわかりません。
ただし、コードが挿入されているページに特別な保護を追加し、試行回数を 3 などに制限することもできます。さらに保護を強化するには、そのページにも電子メール アドレスを送信し、電子メール アドレスごとに 3 回の試行を許可します。簡単にバイパスできる 3 回/IP の代わりに。