パスワードのリセットと変更
私のwebappには「パスワードのリセット」と「パスワードの変更」機能があります。
パスワードの「リセット」は一般的です。ユーザーは[パスワードを忘れた]をクリックしてメールを入力し、そこに1回限りのリンクをメールで送信し、フォームにアクセスして新しいパスワードを選択します。
パスワードの「変更」はより複雑です。 2つの方法があります。
- 一部のサイトでは、ユーザーがログインして「パスワードの変更」をクリックし、古いパスワードを入力し、新しいパスワードを選択するというワンステップのプロセスを使用しています。
- 他のサイトでは、電子メールループの2段階のプロセスを使用します。ユーザーがログインし（HTTPS）、[パスワードの変更]をクリックし、電子メールで送信されたリンクをクリックし、新しいパスワードを要求するフォームにアクセスします。彼の現在のパスワードは要求されていません。これは（おそらく）ログインすることなく行われます！
これら2つはよく似ていますが、トレードオフがあります。
オプション（1）の方が簡単です。ただし、ユーザーのデバイスが盗まれた場合（または、コーヒーを飲みに机から離れたところにいるとします）、パスワードマネージャーを備えたブラウザーを使用している場合、攻撃者はパスワードを知る必要はありません。
オプション（2）は、電子メールで彼を確認するため、現在のパスワードを要求することもありません。しかし、攻撃者が自分のデバイスを持っている場合、おそらくとにかくメールにアクセスできます。また、現在のパスワードを要求し、パスワードマネージャーがインストールされている場合、電子メールループは何も実行しません。
また、「リセット」ワークフローは非常に使いやすいので、「変更」ワークフローを過剰設計すると、ユーザー（および攻撃者）が代わりにリセットフォームを使用できるようになります。
したがって、これはセキュリティの問題ではなく、UXの問題にすぎないと思われます。 2ステップの方がより安全に「感じる」が、それは幻想だと思う。
（UXよりも）セキュリティに優れているのはどれですか。私が無視した考慮事項はありますか？
私があなたの質問で見る問題は、オプション（1）とオプション（2）で述べた脅威は両方とも、攻撃者がシステムに物理的にアクセスできる脅威であるということです。Webアプリケーションを開発しているとき、これらはそうではありませんあなたが心配すべき脅威。
常に覚えておいてください：-
攻撃者がデバイスに物理的にアクセスできる場合、それはもはやデバイスではありません。
攻撃者が物理的にアクセスできる場合、なぜ攻撃者はパスワードを変更しようとするのですか？なぜ攻撃者はパスワードの変更に時間を浪費するのではなく、単にバックドアしないのですか？
ここで、パスワードの変更/リセットについて説明します。記述したワークフローはどちらも、それ自体で安全です。脅威は実装の弱点でのみ発生します。たとえば、次の場合：
- ここでの攻撃者は、ログインするだけでなく、古いパスワードも知っている必要があります。
- ここの攻撃者はあなたのメールアカウントを侵害する必要があります。
どちらの場合も、それが起こった場合はゲームオーバーになります。
私のポイントを強調するためだけに
あなたが書いたワークフローは安全です[〜＃〜] if [〜＃〜]追加の脆弱性なしで正しく実装されています。
「オプション（2）は現在のパスワードを要求することすらありません」：どうすればよいかわかりません。パスワードの変更をリクエストするには、ユーザーは自分のプロファイルにログインする必要があります。これにはパスワードが必要です。ユーザーがパスワードマネージャーでマスターパスワードを使用せず、パスワードを入力せずに効果的にログインすることを意味している可能性があります。これがあなたの場合、あなたは正しいと言っています "しかし私はそれは幻想だと思います"。
あなたは何を考慮すべきですか？
多要素認証を使用します。一般的な2要素認証は、パスワード（ユーザーが知っているもの）とスマートフォンの使用（ユーザーが所有しているもの）に基づいています。スマートフォンの使用法はさまざまです。これは、SMS、確認を要求するプッシュ通知、OTPジェネレーター、写真TANなどです。 PINまたは指紋または顔IDを介して、スマートフォンを保護する必要があります。
実際には、2要素認証があります。しかし、ユーザーがそれを危険にさらした場合（パスワードを使用しないか、スマートフォンをロックすることを気にしないことによって）、それは役に立ちません。
これらの要素のいずれかの代わりに、Google TitanやYubikeyなどのハードウェアトークンを使用できます。 [パスワード+ハードウェアトークン]または[スマートフォン+ハードウェア]トークン。しかし、繰り返しになりますが、ユーザーがトークンを気にしない場合、彼は安全ではありません。
ソリューションを選択するとき、妥協の価格ユーザーアカウントと実装の価格特定のセキュリティを比較します。地元のボウリングクラブのWebサイトを開発している場合は、単純な1要素のパスワード認証で十分な場合があります。オンラインバンキングアプリケーションを開発している場合、ユーザーがビデオを介してサービスデスクによって認証された後にのみ、パスワードの変更などの重要な操作を許可することができます。価格と価値を比較します。
@lonixで強調されているように、パスワードリセットワークフローとパスワード変更ワークフローは似ており、共通部分がありますが、実行レベルで適切に分離する必要があります。ハッカーは資格情報の取得に関心があり、資格情報の処理プロセスのバグ/抜け穴は確実に悪用されます。ログインプロセスに関する追加情報は、ロケーションベースのアクセス制御や最後のリセットの確認などでキャプチャする必要があることを確認しました。また、一部の機密性の高いSaaSアプリケーションは、パスワードのリセットが発生した後の特定の期間まで、アプリケーション操作の機能を制限します。