Crypter-File-Transfer
[Feature] Implement multi-factor authentication
Describe the feature Implement opt-in MFA for registered users.
Supported options should include emailed codes and TOTP.
Responding to this comment: https://github.com/Crypter-File-Transfer/Crypter/discussions/768#discussioncomment-12462362
What is the current status of https://github.com/Crypter-File-Transfer/Crypter/pull/751 ?
It seems pretty close to being complete. Looking at the repository's PR history, it seems I put these changes on hold while I moved some things out of the original login flow. I think the changes in the PR are still relatively fresh and might be a good place to start on the emailed codes. I'm not sure if I had TOTP in mind at that time, though. @ibede You can work off this branch, create a new branch and bring changes in, or start from scratch. Whatever your preference is will be fine with me.
Should we integrate existing OTP implementation like Otp.NET, or implement it internally?
I would be happy using Otp.NET or any other library with a good record.
I think the user shall be able to set their preferred MFA method, and also provide means for fallback mechanism.
Agreed the user should be able to set their preferred MFA method. I agree with the fallback mechanism in principle, but how do you think falling back to TOTP should work in case the user changes their email address? The new email address becomes "unverified" until the user proceeds with email address verification. I prefer not to allow emailed OTP codes for un-verified email addresses.
Perhaps we do not allow email address changes until the user changes their MFA option?
What's your idea for handling situations when the user has no more access to their MFA provider (like a lost mobile phone without fallback)? Account recovery may be an option, but should we provide MFA recovery separately?
New users are instructed to copy and save a recovery key when they login for the first time. We could do something similar for MFA recovery codes... though the user may lose those as well.
I vote we address this later. Assuming that it does not need to be addressed now for the initial MFA implementation.
I think fallback shouldn't be automatic. Let's assume the user has set both mechanisms and selected a preferred one (eg. TOTP) and then loses their phone. On the login page the user fills user/password, it is verified and the system issues a 2FA challenge for a TOTP code. As the user has no phone, we should provide a link/button for having the fallback mechanism: email if it is not the preferred one. Or the user may choose to go with one of the generated recovery codes if we implement it. If 2FA is enabled for the user and their email address changes, I would send an email code as a verification when changing the address. Same way, if the user changes their authenticator app, I would generate a new TOTP secret and after scanning the QR, I would force the user to enter the current TOTP as a verification of the usage of the authenticator application.
I agree with the first part. The user should choose which fallback at the time of login.
The application currently sends a verification email to the new email address when the email address is changed. My concern is what happens when the user does not immediately open that email to verify their new email address; should email MFA be disabled in the interim? Implicitly disabling MFA (in case email MFA was their only option) does not seem wise. Which is why I was considering disabling email change until the user chooses an alternate MFA or disables MFA.
Now I see your point. Yes one option would be to block the change of email. How about separating the two email addresses? By default the MFA address would be the same as the registration email, but they could be different. So when the user changes the registered email address, the verification would be the same as before. The MFA address would stay the same and the user would only be able to change it to the new one if it's already verified. In that case the user should be notified about this when changing the registration email address suggesting to set TOTP as MFA if the previous email address is not available anymore.
Let me ask around about email change scenario. It should be a solved problem.
Notably, Microsoft does not allow users to set their email address as an MFA option.
I think the right approach is to modify how email address changes occur. The old, verified email address should stay active until the user verifies the new email address. Will need to add another column to the database (emailAddressChange).
Thinking out loud.
Added #788 for the email change concern.
I've begun working on #788 and #789.
For the purposes on this issue (#786), the User table's Email Address column can be assumed to be the current, verified email address.