Webアプリケーションでのパスワード変更時に、他のすべてのセッションをログアウトする必要がありますか？
ユーザーが複数のタブでWebベースのアプリケーションにログインし、パスワードを変更した場合、自動的に他のタブからログアウトする必要がありますか？使用例は、アカウントが侵害され、攻撃者がログインし、ユーザーもログインしてパスワードを変更することですが、攻撃者はすでにログインしているため、ログアウトするまでアクセスが許可されます。
これには、パスワードbcryptハッシュをセッションに保存する必要があり、すべての要求がデータベースのbcryptハッシュに対してセッションbcryptハッシュをチェックします。別のアプローチはありますか？
TL; DR：パスワードを変更しているのが攻撃者ではないことをどのようにして知っていますか？その場合、正当なユーザーをログアウトします。または、ユーザーは定期的にパスワードを変更することをお勧めしますが（ただし、毎回すべてのデバイスに再度ログインする必要がある場合は不要です）。他のすべてのセッションをログアウトするには、（1）ユーザーが[他のすべてのセッションをログアウト]ボタンをクリックするか、（2）ユーザーがパスワードを忘れた場合の機能を使用します（これにより、電子メールアドレスを確認するか、その他の強力な機能を使用します）それがパスワードではないことを証明します）。
他のすべてのセッションをログアウトするタイミングはいつですか？
ユーザーのパスワードが変更されるいくつかのケースがあります：
- ユーザーが侵害に気づいたか疑わしい場合、パスワードを変更
- 攻撃者がアカウントへのアクセス権を取得し、ユーザーのパスワードを変更した
- ユーザーがパスワードを忘れた
- 攻撃者はユーザーの電子メールアカウントを侵害し、パスワードを忘れた機能を使用します
- ユーザーは、セキュリティを向上させると考えているため、またはポリシーのために、定期的にパスワードを変更しています。
どちらの場合も、異なる選択をしたいと思うでしょうが、正当なユーザーと攻撃者を区別することは不可能です。パスワードを忘れた場合の機能を使用する場合、ユーザーにパスワードの確認を要求することはほとんどできないため、攻撃者がユーザーのメールアカウントを侵害した場合を無視するか、別の方法を使用してユーザーの身元を確認する必要があります（たとえば、最近の購入、 SMS確認コード、セキュリティの質問[1]など）。
インターフェースから変更されたときに誰がパスワードを変更しているのかわからないので、他のセッションをアクティブのままにしておくのは無理はないと思います。その場合、ユーザーがパスワードリセットを行ったときに他のセッションを終了する必要があります（後パスワードリセットリンクを確認しました。フォームに電子メールを入力するたびにではなく、不正使用される可能性があるためです）。両方がログインしてパスワードを知っているシナリオを想像してみてください。両方がパスワードを変更しようとし（お互いを知っていると仮定）、最初にそこに到達するのは運だけです。しかし、パスワードリセット機能が誰かによって正常に使用されると、これが正当なユーザーであるという確信が高まります。
別の考慮事項は、他のセッションをログアウトするための個別のインターフェースを使用するかどうかです。おそらく、他のすべてのセッションと過去のログインのリストの横に、「他のすべてのセッションをログアウト」するためのボタンを設けることができます。 これをお勧めします。これは、ユーザーが自分のアカウントに異常が発生したときに何が起こっているかを確認できるためです。攻撃者は自分の存在を隠すことができなくなります。
セッションの管理方法は？
理想的には、すべてのアカウントのアクティブなセッションのリストと、ログインの履歴が必要です。ログインの履歴は、特定の数のログインではなく、特定の時間だけ遡る必要があります。最後のXログインのみが表示されている場合、攻撃者はアカウントの履歴を調べ、ユーザーエージェントと国/州/を偽装しますVPNを使用する都市、およびXログインを実行して、自分のログインをメモリからプッシュします。
これは、各ログインセッションが登録されているデータベースで管理できます。 expires列を使用して、期限切れのセッションをパージできます。もちろん、セッションはログアウト時に削除されます。これはログインロギングとは別であることに注意してください。ログアウトしても、<device>を使用してアカウントにログインしたことが<locationから表示されているはずです>on<datetime>。削除する（またはブール値を切り替える）唯一のことは、セッションがアクティブであることです。
質問で説明されているように、bcryptハッシュ化されたパスワードを使っていくらかのトリックを行う必要はありません（そして、絶対にお勧めしません！）。セッション状態は、設計上、ユーザーのパスワードから独立している必要があります。それ以外の場合、セッショントークンには意味があり、これは推測される可能性があります攻撃者がパスワードを本当に知らなくても、小さな間違いがいくつかあります。または逆に、攻撃者が取得したすべてがセッショントークンである場合、オフラインのブルートフォースを通じてパスワードを知る可能性があります。
一般的に言えば、少なくとも2つの列（セッショントークンとユーザーの一意の識別子）を持つセッションのリストが必要です。セッショントークンはランダムバイトであり、オプションでハッシュされます（侵害された、または弱いPRNGからデータをリークしないため）。ユーザーの一意の識別子は安定している必要があります。表示名はなく、できればユーザー名ではありません。 MariaDB/MySQLの自動インクリメント列など、使い捨ての一意の識別子を使用します。通常、3番目の列、有効期限が追加されますが、これは厳密には必要ありません。ただし、evenを複数年に設定する場合は、強くお勧めします。
リクエストごとに、データベースでセッショントークンの存在を確認できます。ユーザーが他のセッションを無効にする操作を行った場合、ユーザーの他のセッションを非アクティブ化（または削除）するのは簡単です。
[1]実行しないパスワードの代わりにセキュリティの質問を使用します。私がそれをあえて言及する唯一の理由は、それが追加である可能性があるためです：ユーザーが自分のメールアカウントに送信された秘密コード（またはリンク）を確認したとき、またはそれを証明したとき彼らは自分のパスワードを知っているので、それを使用して、それが実際のユーザーであり、攻撃者ではないことをもう少し確実にすることができます。
ユーザーが複数のタブでWebベースのアプリケーションにログインし、パスワードを変更した場合、他のタブから自動的にログアウトする必要がありますか？
ユーザーがCookieベースのメカニズムを使用してログインしている場合、1つのタブからログアウトすると、ユーザーはすべてのタブからログアウトします。パスワードを変更するだけの場合は、現在のタブでセッションにログインしたままなので、他のタブでログインしたままになります。 Gmailのマルチセッション機能などの特別な機能を実装していない限り、同じブラウザの各タブは同じセッションになります。
ユースケースは、アカウントが侵害され、攻撃者がログインし、ユーザーもログインしてパスワードを変更することですが、攻撃者はすでにログインしているため、ログアウトするまでアクセスが許可されます。
はい、これはASP.NETのフォーム認証などの一部のシステムで発生する可能性があります。
デフォルトのフォーム認証 SignOut メソッドはサーバー側を更新せず、キャプチャされた認証トークンを引き続き使用できるようにするか、パスワードが変更されたセッションが引き続き有効になります：-
SignOutメソッドを呼び出すと、フォーム認証Cookieのみが削除されます。 Webサーバーは、後で比較するために有効な期限切れの認証チケットを保存しません。これにより、悪意のあるユーザーが有効なフォーム認証Cookieを取得した場合に、サイトがリプレイ攻撃に対して脆弱になります。
これには、パスワードbcryptハッシュをセッションに格納する必要があり、すべての要求がデータベースのbcryptハッシュに対してセッションbcryptハッシュをチェックします。別のアプローチはありますか？
はい、セッションをサーバー側で追跡できます。たとえば、暗号化されたセキュリティで保護された文字列を、Cookie値として設定され、リクエストごとにデータベースで検索されるセッションIDとして割り当てます。
別のアプローチは、すべてのリクエストでチェックされる認証クッキーの一部として、パスワードの最終変更日時のハッシュを保存することです。
明らかに、これらはデータベース接続とは無関係にチェックできるセッションIDと比較してパフォーマンスに影響を与えますが、これらの値が適切に期限切れである限り、これらの値をキャッシュすることは可能です。サーバー側に保存されているセッションIDの場合、スライドする有効期限が必要な場合にセッションを存続させるために、適切なメカニズム（ここでもオーバーヘッドあり）が必要です。
ユーザーがログアウトするか、パスワードを変更すると、セッショントークンが取り消されます。これは通常、fc2904-92385-4jf9のように、ユーザーを識別するハッシュです。
サーバーは、特定のセッショントークンが不適切であることを認識している必要があります。そのため、他のウィンドウでアプリケーションを開いていて、ブラウジングを続行しようとすると、サーバーはトークンの期限切れのためにすべての要求を拒否します。
ユーザーが自分のアカウントを侵害しただけでなく、さまざまな理由でパスワードを変更した。そのため、パスワードを変更した後に、開いている他のセッションを終了することは、ユーザーエクスペリエンスの観点からはまったく好ましくありません。
ただし、ユーザーの利便性を維持しながらこの特定のケースで完全なユーザー保護を実現するには、現在のセッションでユーザーが次に行うアクションの前に、ユーザーにパスワードの入力を求めることをお勧めします。