Password and 2FA reset/Confirming identities
Appearance
How to confirm identities
In the best case, the user has a committed identity, and can prove their ownership of the account. After the user confirms their identity by presenting the string/file used to generate their hash, they should regenerate their committed identity (since they are no longer the only person who knows it).
In other cases, you will need to do some research to find out if the person who is making the request really is the owner of the account. Here are some strategies for confirming account ownership:
- A user's identity and request can be confirmed by a trusted user. If a Steward or other trusted functionary knows the user in real life, and can verify the situation with the user (via a phone call, or other difficult-to-spoof mechanism) then we can trust these references and reset the user's password.
- Other ways that we have verified user's identities. If more than one of these can show a user's identity, we can be more sure that the request is legitimate:
- Other accounts known to be controlled by the user (bot accounts) can make a requesting edit
- Accounts with known relationships (UserAccount1 specified that they were creating an account UserAccount2 for a family member. Both accounts have the same email address. UserAccount2 makes an edit vouching for the change request of UserAccount1).
- If the user has a static IP, and a checkuser can verify that the user and the request come from the same IP.
- A user's old (pre-SUL) email address can sometimes be found in a local wiki's user.user_email column. That is sometimes useful as an additional voucher in case an old email should be restored.
Process to re-claim accounts
- Lock the account for a few days so if the request isn't legitimate, the real owner will likely notice that something is going on.
- Change / set the email address on the account.
- Have the user initiate a password reset, or initialise the reset for the user.
- Notify someone like Trust and Safety?