While the proposed solution of validating the password on every load is possible and quick to implement I wouldn't do it. Since md5 and sha have been found to be insecure we're using proper hashing systems now, see Phalcon\Security, this becomes quite expensive in cpu cycles. That is deliberate, the more expensive it is to generate a password the longer it will take to be able to break them.
For logins and the occasional password change that's no problem, but if you start hashing passwords on every load, for every user.. maybe it's not so good an idea.
What you want to do is create a token when a user logs in. Add a table token
to your database, the structure could be something like: id
, user_id
, token
, created_on
, used_on
. Whenever a user logs in you create a new token and store the id of the token in the session. When the token stops being available, you redirect back to the login page. At this point I'm sure you've figured out how this works.. whenever a user changes their password you can remove the tokens associated with the user_id
and voila, they'll be logged out everywhere.
There's an added bonus, you can use the token
field, which has a random string (md5 or sha are fine here) and store it in a cookie. If they reach the login page and you detect a cookie named login_token
or whatever you test the string against the database, make sure the token isn't too old to use (that's what used_on
is for, you update that every login or even every page load, it'll still be cheaper than validating the password every load) and log them in.
Bonus points for using a redis or other key/value store for your token storage, it'll be even faster.