Page MenuHomePhabricator

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
Open, HighPublic

Description

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.

Event Timeline

Tgr created this task.Jul 1 2015, 9:24 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 1 2015, 9:24 PM
leila added a subscriber: leila.Jul 1 2015, 9:30 PM
Legoktm added a subscriber: Legoktm.Jul 2 2015, 2:06 AM

We should get rid of old local password hashes at the same time too.

csteipp triaged this task as High priority.Jul 2 2015, 6:50 PM
csteipp added a subscriber: csteipp.

I would really like to see this done (both email and hashes)

Tgr renamed this task from Local old email addresses should be discarded after a successful address change to Old versions of sensitive user data (email, password hashes) can remain in database indefinitely dues to local and global DB not being kept in sync.Jul 2 2015, 10:32 PM
Tgr updated the task description. (Show Details)
Tgr set Security to None.
Tgr added a comment.Jul 2 2015, 10:40 PM

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.

Tgr added a comment.Jul 2 2015, 10:42 PM

Getting rid of login data from local tables will make implementing the public/private service split RFC easier as well.

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJul 4 2015, 5:45 PM
Nemo_bis renamed this task from Old versions of sensitive user data (email, password hashes) can remain in database indefinitely dues to local and global DB not being kept in sync to 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.Jul 18 2015, 6:51 PM
Krinkle raised the priority of this task from High to Unbreak Now!.Jan 28 2016, 9:40 PM
Krinkle lowered the priority of this task from Unbreak Now! to High.
Krinkle moved this task from Incoming to To-do on the MediaWiki-extensions-CentralAuth board.
Tgr updated the task description. (Show Details)Apr 21 2016, 10:57 PM
ZhouZ added a subscriber: APalmer_WMF.
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptMay 27 2016, 7:54 PM
ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.May 27 2016, 7:57 PM

@JBennett Probably of high interest to you

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)

Tgr added a comment.Jul 31 2018, 12:35 PM

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.