When a user changes their password or email address, it will be updated on the wiki where they did the change, and in the global database. It won't be updated in other wikis in the same CentralAuth cluster, however. (Email will be updated when AuthPlugin::updateUser is called on that specific wiki; IIRC this only happens when the user logs in manually - via Special:UserLogin - on that specific wiki. Password does not seem to be updated at all.) This won't affect MediaWiki's operation as these fields will be read from the global database anyway, but it means that old email addresses and password hashes can persist indefinitely in the database. This arguably violates the data quality principle, a fundamental rule of EU privacy regulation, and is in general a privacy and security problem - we should not store private data that we don't need, much less old passwords which might still be in use somewhere else, or might be used to guess the new password. It can also lead to mistakes when people look for email addresses at the wrong places.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | BUG REPORT | None | T104500 Old versions of sensitive user data (email, password hashes) can remain in database indefinitely due to local and global DB not being kept in sync | ||
| Resolved | PRODUCTION ERROR | Bawolff | T57420 Remove local wiki password hash when CentralAuth has attached account | ||
| Restricted Task |
Event Timeline
One option is to get rid of local user data completely: set user_password and user_email to NULL, make CentralAuthPlugin::updateUser ignore the local email, and use some step in the registration process (CentralAuthPlugin::initUser?) to avoid the data getting in the local table in the first place during registration.
The other is running a job on global changes to change data in all local wikis as well (and then do a one-time run of that job for all users).
The first seems preferable, if it can be done without breaking anything.
Getting rid of login data from local tables will make implementing the public/private service split RFC easier as well.
Pinging this because it's come up in a review of some of our privacy questions, it would be really good to try and find a way to resolve this. For me it's mostly the email question. A user who is removing or changing their email can understandably assume that they are removing the old version from our record and we tend to tell people this. Unfortunately this issue means that not only do they not realize that the email continues to exist elsewhere the ability to remove it is now out of their hands. If they go to another wiki and look at their preferences (for example) it will still say they don't have an email address set because the preferences are checking the global database.
See related security issue T179900 (which we've seen at least a couple independent complaints about so can be found)
I've been working on removing passwords (on hold now since the work on JS editing permissions turned out to be unexpectedly time-consuming), it's tracked in T57420: Remove local wiki password hash when CentralAuth has attached account. That probably should be a subtask.