When a user is logged into a web-based application in multiple tabs, and changes their password should it automatically log them out of the other tabs?
If a user is logged in using a cookie based mechanism then logging out of one tab will log the user out of all tabs. If they only change their password, then as they will still be logged into the session on the current tab, they will remain logged in on the other tabs. Unless you have implemented something fancy such as the multiple session functionality of Gmail, then each tab on the same browser is the same session.
The use case is an account is compromised, the attacker logs in, the user also logs in and changes their password, however, since the attacker was already logged in, they are still granted access until they log out.
Yes this can happen on some systems such as Forms Authentication in ASP.NET.
The default Forms Authentication SignOut method does not update anything server side, allowing a captured auth token to be continued to be used or a session with a changed password will continue to be valid:-
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.
This seems to require storing the password bcrypt hash in session, and then every request check the session bcrypt hash against the bcrypt hash in the database. Is there an alternative approach?
Yes, you could either track sessions server side. For example, assigning a cryptographically secure string as the Session ID which is set as a cookie value and is looked up in the database for each request.
Another approach is to store a hash of the password last changed date/time as part of the auth cookie which is checked on every request.
Obviously these have performance hits compared to a Session ID that can be checked independently of any database connectivity, but it would be possible to cache these values as long as they are expired appropriately. In the case of the Session ID being stored server side, you would also have to have the appropriate mechanism (again, with overhead) to keep sessions alive if a sliding expiration was required.