パスワードリセットURL戦略
私たちが開発している「パスワードを忘れた」機能の新しいフローを設計しているときに、URLと、フロントエンドとバックエンドの開発者間で行わなければならないコミットメントに関する難しい質問に遭遇しました。
それは問題ではありませんが、読者の理解を深めるためにフローを適用します。
- メールのリセットをリクエストする（フロントエンド）
- 指定された電子メールが存在するかどうかにかかわらず、応答を送信しますOK（バックエンド）
- ランダムなリセットハッシュを生成します（スパムが発生しないようにするため、存在せず、期限が切れていない場合）（バックエンド）
- リセットリンク@ユーザーのメールを送信（バックエンド）
- パスワードリセットフォーム（フロントエンド）を使用してURLにリダイレクトする
そして、問題が発生する点があります。
フロントエンドに送信する必要のあるユーザー識別子をフロントエンドが認識できるように、フロントエンドに（URLを使用して）送信する必要がある情報は何ですか？
私の最初の考えは、フロントエンドが新しいユーザーのパスワードをEメールのハッシュと一緒に送り返す必要があるため、サーバーはリセット要求と一致するハッシュからユーザーの情報を取得することです。誰かがハッシュをブルートフォースし、パスワードリセットページを見つけたとしても、パスワードを変更しているユーザーを知ることはできません。
2要素認証機能が存在しない場合、ここに何か不足していますか、これがリセットURLを処理する最も安全な方法ですか？
これは大規模な軍団がリセットリンク機能をどのように処理するのですか？
前もって感謝します！
フロントエンドに送信する必要のあるユーザー識別子をフロントエンドが認識できるように、フロントエンドに（URLと共に）送信する必要のある情報は何ですか？
可能であれば、フロントエンドに情報を送信しないでください。一部のサイトでは、挨拶を表示するためにユーザー名を取得しますが、私もそれを避けます。
完全なワークフローは、
- メールのリセットをリクエストする（フロントエンド）
- 指定された電子メールが存在するかどうかにかかわらず、応答を送信しますOK（バックエンド）
- ランダムなリセットハッシュを生成します（スパムが発生しないようにするため、存在せず、期限が切れていない場合）（バックエンド）
- リセットリンク@ユーザーのメールを送信（バックエンド）
- メールリンクのランディングページで、URLからハッシュを取得し、ハッシュが有効かどうかを確認します
- 期限切れ、無効なリンクなどの場合にエラーページにリダイレクトします...（ここでは、メールを取得しているときのように、ここでOK応答を偽らないでください。通常、ここでエラーが発生する可能性があります。そして一部はパラメータを削除するかもしれません）
- または、reset-formにリダイレクトし、ユーザーからパスワードを取得して、ハッシュと一緒にバックエンドに送信します。
- ハッシュを使用してユーザーを照合し、新しいパスワードを更新します。
- ユーザーに成功画面を表示し、メールを送信して、ログインページにリダイレクトします。