はじめに

Webアプリケーションで、**利用者が「パスワード変更」**を行ったら、そのユーザのHTTPセッションをすべて破棄する。
という実装を一般的なWebアプリケーション・フレームワークではどのように実装するのかという点について考察した。

なぜこれが必要なのか

ユーザのHTTPセッションが、不正行為者にハイジャック(乗っ取り)されている場合、利用者はパスワード変更で不正行為者が乗っ取っているHTTPセッションを破棄することができる。

しかしながら、パスワードが漏洩している場合は、不正行為者が先にパスワード変更されると**「おしまい(パスワード変更での2要素認証は必須)」**だが、不正行為者よりも先にパスワード変更ができれば、不正行為をその時点までに止めることもできる。

(セッションハイジャックされた原因がそのままだと、再度ハイジャックされるかもしれないが・・・)

一般的なWebアプリケーションのHTTPセッション管理の仕組み

一般的には**「セッションID方式」だと思う。
このセッションID方式によるHTTPセッション管理は、「セッションID」**と呼ばれる一意で推測困難な値を、Webブラウザの(多くは)クッキーに埋め込み、その値を元にHTTPリクエストをどのHTTPセッションか認識する、というものである。
さらに、セッションIDごとにWebアプリケーション・サーバ側にメモリ(セッション変数/セッションオブジェクトと呼ばれる)が確保されて、データを保持することができる。
この方式の特徴としては、HTTPセッション間は独立であるので、「パスワード変更したユーザかどうか」を見極める仕組みがひつようとなる。

解決策

ログイン時にセッション変数/セッションオブジェクトに何かを記憶させておき、このセッションの年齢というか生存期間が判断できるようにする。
全てのHTTPアクセスのサーバ側の処理の一番最初で、この値をデータベース側の値と比較し、古ければ強制的にログアウトさせる。
(ログイン画面へリダイレクトさせる)

具体的解決策1

セッション変数に、パスワードの更新日時を保持し、その値とデータベース側の最新のパスワード更新時間を比較し、
過去のものであれば、セッションを破棄(ログアウト)し、ログイン画面へリダイレクトさせる。

具体的解決策2

セッション変数に、ログイン日時を保持し、その値とデータベース側の最新のパスワード更新時間を比較し、
過去のりものであれば、セッションを破棄(ログアウト)し、ログイン画面へリダイレクトさせる。

その他

他のやり方もあると思う。
そういうのはコメントに書いてほしい。

以上