Web Development

Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world

This is something of a hybrid. There will be both general public users as well as staff. So for staff, we could just call them or walk down the hall and verify them but the public accounts are what I'm trying to cover (and, ideally, the staff would just use the same method as the public).

Figure if an attacker attempts the 'forgot password' method, it's assumed they have access to the users email.

Yep, that's part of the current posture. If MFA is enabled on the account, then a valid TOTP code is required to complete the password reset after they use the one-time email token. The only threat vector there is if the attacker has full access to the user's phone (and thus their email and auth app) but I'm not sure if there's a sane way to account for that. It may also be overkill to try to account for that scenario in this project. So we're assuming the user's device is properly secured (PIN, biometrics, password, etc).

If you are offering TOTP only,

Presently, yes, but we're looking to eventually support WebAuthn

or otherwise an OTP sent via SMS with a short expiration time

We're trying to avoid 3rd party services, so something like Twilio isn't really an option (nor Duo, etc). We're also trying to store the minimum amount of personal info, and currently there is no reason for us to require the user's phone number (though staff can add it if they want it to show up as a method of contact). OTP via SMS is also considered insecure, so that's another reason I'm looking at other methods.

"backup codes" of valid OTPs that the user needs to keep safe and is obtained when first enrolling in MFA

I did consider adding that to the onboarding but I have my doubts if people will actually keep them safe or even keep them at all. It's definitely an option, though I'd prefer to not rely on it.

So for technical, human, and logistical reasons, I'm down to the following options to reset the MFA:

1. User must contact a staff member during business hours to verify themselves. Most secure, least convenient.
2. Setup security questions/answers and require those after the user receives an email token (separate from the password reset token). Moderately secure, less convenient, and requires us to store more personal information than I'd prefer.
3. Similar to #2 except provide their current password and a short-term temporary token that was emailed to them when they click "Lost my MFA Device". Most convenient, doesn't require unnecessary personal info, possibly least secure of the 3. Note that password resets require both email token and valid TOTP token, so passwords cannot be reset without MFA.

I'm leaning toward #3 unless there's a compelling reason not to.

I thought about generating a list of backup codes during the onboarding process but ruled it out because I know for a fact that people will not hold on to them.

That's why I'm leaning more toward, and soliciting feedback for, some method of automated recovery (email token + TOTP for password resets, email token + password for MFA resets, etc). I'm trying to also avoid using security questions but haven't closed that door entirely.