Our app is constantly being rejected because it contains 2FA to protect editing the user's profile. The user's profile can only be edited after entry of a validation code that is sent by text message to the valid US mobile number recorded for the user. Since we do not have the cell phone number of the reviewer, we cannot make that phone number part of the demo account and as a consequence the reviewer does not get the validation code and cannot get access to the profile edit functionality. The app gets rejected and even the app review bosrd continues to tell us we have to "provide demo account information" to provide access to the entire app.
Obvisouly, we cannot provide the validation code, as it is app generated and an integral part of the submitted app. It is not the same as a password, but the app store reviewers don't seem to understand. Any way around this?
App rejection with two factor authentication
Hello LHDMulder,
This is a very common problem for applications leveraging SMS as a second factor of authentication.
The simplest solution that I have found and leveraged is being able to build a simple online service that the App Review team can go to (include link in the Review Notes) that displays the SMS authentication codes provided for that specific test number within the last X number of minutes.
You could even provide authentication credentials for the web service in the Review Notes if you are concerned with the solution being on the internet.
This of course takes a bit of work, but we have gotten multiple applications through the App Review process like this.
Hopefully this helps!
I'd do what ever I needed to reduce friction. Perhaps enhace the system with a flag for "special" accounts to bypass 2FA. If the reviewer doesn't get stuck on 2FA then that shouldn't be a problem.
This potentially opens the door to the app having functionality they were unable to review, but I would think a 2FA authentication step wouldn't be something significant enough for them to make noise about in that respect.
I am trying this approach now, thanks for the suggestion. I appreciate the help.
I think this could work, but as you mentioned, a lot of work for something that should not lead to rejection. The reviewer could make a valid cell phone number available to actually review this 2FA functionality as a real user would use it. I am getting no response to this suggestion however, the exact same "bot" type response that we have to provde a demo account (which we have; the feedback makes no sense).
Shut off the two factor authorization requirement until the app is approved. Make a note to App Review that because they do not have the ability to participate in two factor authorization you have disabled it for their review.
I have a primary app that has always used 2FA for four years now - Apple has always gone through the app register process using one of their own internal phone numbers and in four years have only rejected an app update once. We explained they have done it before (for years) - the reviewer somehow managed to find that registration (or phone number) and were able to get the app registered. App was always accepted without the need of a special account.
So...they CAN do it. But it always seems to come down to who is reviewing your app on what day. This week, we have submitted another app (on the same developer account as the primary app) and we are getting constant app rejection for the SAME 2FA authentication scheme as our primary app.
Its not about security for the reviewers, its about convenience. They CAN do it....some chose not to and reject your app as a result. Zero consistency...which is Apple's hallmark in the world of software development. Part of the app review process is validating the app is secure, doesn't contain malicious code, isn't fraudulent, etc....and the first thing Apple does is reject your app because you employ stringent 2FA security.
Again....the irony....or is it hypocrisy?
Once Apple is done testing, that test account is going to be disabled altogether, so it's not really a security risk.
We have had similar issues with this topic with an SMS-based Multi-Factor Authentication System.
As we didn't want to bypass our production security mechanisms or re-develop a demonstration mode, we have used a platform allowing to assign temporary virtual phone numbers to users in our apps. The platform is called GetMyMFA (get.mymfa.io) and it allows us to review and approve our app within 24 hours.
To use it we simply created a user in our production application with a virtual phone number attached which we can enable and disable in real time for the App Store review process. That way Apple simply needs to log in to the platform (with a specific and private username/password) and the SMS MFA login code is displayed in the website.
By using this platform we have been able to:
- Avoid spending time in a security "bypass" (and all the security issues that often come with it)
- Avoid building a "demonstration" mode exclusively for Apple
- Avoid using public websites with public phone numbers accessible to anyone.
Our App gets approved within 24h with this system and the user can be easily and safely disabled after the review process is completed.
Hi Frajedo, can you explain me your solution with bypass with getmymfa? I have exactly the same problem trying publish my app in AppStore.
Thx in advance!,
Jose
Hello @Jose_Ignacio,
We simply have created an actual production user account in our application, and linked to it a virtual phone number from the GetMyMFA platform. We then shared with apple the login information to the GetMyMFA platform in the Application description for review purposes, and whenever they try to connect, they are able to access the MFA code through the GetMyMFA platform.
Let me know shall you need any additional information.
All the best.
Just disable MFA/2Factor for that user