Webページを使用してパスワードを変更する場合、同じ画面で古いパスワードを入力する必要がありますか？
以下に示すように、古いパスワードが変更されているページと同じページで常に古いパスワードを要求する規則があります。
ユーザーがログインできるようにし、古いパスワードを必要としない別のページでパスワードを変更することは、セキュリティの観点から受け入れられますか？
私はモバイルアプリケーションを合理化しようとしているので、標準のWebアプリケーションを同じワークフローにすることを検討しています。
ユーザーの「煩わしい」ワークフローの例：
ユーザー認証
ユーザーにPWの有効期限が切れている、または（すぐに）変更する必要があることが通知されます
以下の画面が表示されます。 「現在のパスワード」を求める追加のプロンプトは煩わしいものであり、どのような利点があるのでしょうか...
新しいパスワードを選択するときに現在のパスワードの入力を要求されるのは、変更を行う人が「実際の」アカウント所有者であることを確認するためです。
ログイン後に直接パスワードを変更できる場合、次の攻撃が可能です。
- あなたは一瞬コンピュータから離れて、私はウェブサイトに行きます
パスワードを変更します - ログインCookieを盗み、ウェブサイトを読み込み、パスワードを変更します
編集：次のシーケンスを提案している場合：古いパスワードを使用してログインし、次のページで新しいパスワードの入力を求めるプロンプトが表示されたら、「変更」画面がしばらくしてタイムアウトになると想定して、おそらく同じレベルの保護があります。
プロセスがいくつの画面を使用するかは重要ではないと思います。重要なのは、「実際の」所有者がサイトとやり取りしたことを確認できる期間と、パスワード変更要求が発行されるまでの期間が短いほど、セキュリティが向上することです。
新旧のパスワードフィールドを同じページに配置することで経過時間をゼロに設定できるため、UXの変更が（IMHO）少ないため、おそらくそのように行われているのはこのためです。
これを行う目的は、ユーザーがセッションから離れることを防ぎ、攻撃者がセッションを制御してユーザーのパスワードを変更するのを防ぐことです。
したがって、攻撃軽減の観点から考えると、攻撃とは、既存のセッションにホップして資格情報を変更することです。緩和策は、資格情報を変更する前に特定時点の認証を要求することです。
モバイルシナリオでは、理論上、ユーザーは常に携帯電話を持っていて、攻撃者が有害なことを行うためにセッションが（十分長く）放棄されない可能性があります。
ただし、実際には攻撃者は理論的には非モバイルセッションをモバイルセッションに変換し（たとえば、デスクトップセッションにホッピングし、Cookieを盗み、Cookieをモバイルセッションに添付する）、ポイントをバイパスできるため、実際には機能しません。時間認証チェック。
これは、機能/経験とセキュリティ対策の間のトレードオフです。 2番目のシナリオを安全に機能させるには、攻撃者がセッションを変換したり、既存のモバイルセッションに自分自身を注入したりできないことを確信する必要があります（これらの攻撃を緩和する必要があります）。
私の意見では、いいえ、それは許容できません。その理由は、パスワードの変更はトランザクションイベントであり、パスワードを変更するユーザーがそのトランザクションの実行を許可されているユーザーであることを確認する必要があり、現在のパスワードを知っていることを確認することで認証するためです。