[DOCS] Document the Exact Requirements for 2FA Reset

[SudharakaP]

This is with regard to the following comment.

We still need to document a procedure internally for people who have no recovery code and want to reset 2FA (we had a few of them already) to define what criteria we want to use based on the account level (contributor, host admin, etc). But it's handled manually atm, and not overwhelming so there's no rush.

Originally posted by @Betree in #3709 (comment)

I think we need properly document the process we follow in order to reset the 2FA. Currently my understanding is that this is done manually on a case by case basis. On this regard I suggest looking into the following.

• What information we need from each user category (contributor, host, admin etc) in order to reset the codes.

• What specific information we need from users who have payment methods configured (Bank Account for example).

@Betree : Please feel free to add anything I am missing since you probably have lot of experience on this regard. 😄

[Betree]

Some approaches I've taken so far with support tickets:

• Reset 2FA directly for accounts that were empty
• Asked for an ID for an account that was using its real name and had admin permissions on a host
• Asked for a proof to be added on a repo (a file with a random UUID) for a collective admin to make sure they are admin of the repo, as the person was using a pseudonym.
• Asked for the last 4 digits of the credit card

[SudharakaP]

For this I would suggest the following approach;

• If user has Twitter, GitHub or any other social accounts linked we can ask for a proof to be added to them.
• If the user has a payment method linked, we can ask for the credit card information (last 4 digits + type of card etc).
• If the account is completely empty, but the user is an admin of another collective or host (where there's other admins), we notify the other admins of the collective to verify if it's okay to reset the user's 2FA codes.
• If the account is completely empty, but the user is the sole admin of another collective or host, we look at any links in the collective or host account (such as the website link) and ask the user to upload something to those social links in order to verify. For example if the collective has a twitter account we ask the user to post a message with that account.
• If none of the above, there's no links to social accounts, there's no credit card information and the user account is completely empty we just reset them as there's nothing to lose.

cc: @Betree

[Betree]

@SudharakaP This is good, but we should be careful with socials as well. If someone gets their email hacked the attacker probably has access to their socials. The good part about asking for a Github commit is that it can be signed with your private key, which brings a little more security. But the goal of 2FA is to protect you even if your email address gets hacked, so we should be really careful with this.

That's where it's difficult to come up with very precise rules, if an OSC admin asks me to reset 2FA social networks posts won't be enough for me. I'll try and find an additional way to verify their identity, such as jumping in a video call or asking for an ID. I think we need an additional set of rules for "very important profiles" (e.g. OSC admins, OCF admins, OC admins, Google admins, etc.).

We're also missing a last rule in case someone doesn't fit in any of these bullet points. Let's take a practical case: someone contacts support and asks to reset 2FA on a profile that has a recurring contribution set up. He's unable to provide the last 4 digits of the card (e.g. because it was done through PayPal) and there's no social connected. What do you do?

[SudharakaP]

@Betree : Thanks for the ideas. As you say maybe it's hard to exactly come up with rules that cover all situations. But then I believe maybe we can make sure that all the simple cases are covered and the ops staff can always triage more complicated cases like OSC admins for further review by the dev team. I've added the notes at, opencollective/opencollective-frontend#8598 (comment).

As for the case where a person is unable to provide the last 4 digits of the payment method (using PayPal) what we could do is if there's no other way to verify to cancel the recurring contributions on file and then reset the 2FA code? 🤔

[Betree]

As for the case where a person is unable to provide the last 4 digits of the payment method (using PayPal) what we could do is if there's no other way to verify to cancel the recurring contributions on file and then reset the 2FA code?

My example was a bit misleading since, in practice, you can usually find the last 4 credit card digits (or bank account info) for PayPal contributions. But what I wanted to surface here is that, if someone is not able to provide convincing proof that they own the account, then we should be ok with refusing to reset 2FA for them. Eventually, cancel the recurring contribution if you're confident enough, but don't give access to an account if you're not sure the request is legit.

[SudharakaP]

As for the case where a person is unable to provide the last 4 digits of the payment method (using PayPal) what we could do is if there's no other way to verify to cancel the recurring contributions on file and then reset the 2FA code?

My example was a bit misleading since, in practice, you can usually find the last 4 credit card digits (or bank account info) for PayPal contributions. But what I wanted to surface here is that, if someone is not able to provide convincing proof that they own the account, then we should be ok with refusing to reset 2FA for them. Eventually, cancel the recurring contribution if you're confident enough, but don't give access to an account if you're not sure the request is legit.

True. There's many places for example GitHub which mentions that if you lost 2FA codes then you might not be able to recover the account. We could do this too I think and only reset the code unless we are absolutely sure and just deny other requests. Although in this case we need to probably have a warning such as this one in the docs and where we setup 2FA.

[Betree]

@SudharakaP Exactly. We shouldn't be afraid of implementing such measures, it's the goal of 2FA to lock people out if they cannot confirm their authorization - even if it's disappointing for them.

[Betree]

Interesting policy from GitHub: https://github.blog/changelog/2023-02-21-unlink-your-email-in-case-of-2fa-lockout

[shannondwray]

This is complete? @SudharakaP

https://coda.io/d/Support_dEguIswyoKq/Reset-2FA_su-JA?searchClick=500a1ee1-bf04-4ffd-8e0c-f4d5cfc3867f_EguIswyoKq#_luuHs

[Betree]

My initial feedback has been answered; I'm OK with this issue being closed.

I've added a comment on the documentation page @shannondwray linked, as I think there's still room for improvement. It's a complex topic, but you all did a great job coming up with this first version; it's a good framework.