If the requirement is "access tokens become invalid when the password is changed," then you should simply delete (or mark as deleted) the affected access tokens from the server-side database inside the ChangePassword() function.

Session ids are often just ephemeral access tokens, and any other sessions for the same user should also be deleted from the server's session store when the password is changed. I would keep just the one session that actually issued the change password request, as I hate it when sites log me off when I change my password, forcing me to enter the new password a 3rd time.

Since an access token trumps the password, perhaps it should be equally hard to derive an access token given the database dump as it is to derive a password. In this case, you would want to use bcrypt for hashing the access token, the same way you use bcrypt for hashing the password itself. Alternatively, make sure the keyspace for your access tokens is 'very large'. But if hackers have read access to your database, perhaps brute forcing access tokens is the least of your concerns.